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Abstract 

Secure  group  communication  is  crucial  for  building 
distributed  applications  that  work  in  dynamic  envi¬ 
ronments  and  communicate  over  unsecured  networks 
(e.g.  the  Internet).  Key  agreement  is  a  critical  part  of 
providing  security  services  for  group  communication 
systems.  Most  of  the  current  contributory  key  agree¬ 
ment  protocols  are  not  designed  to  tolerate  failures 
and  membership  changes  during  execution.  In  par¬ 
ticular,  nested  or  cascaded  group  membership  events 
(such  as  partitions)  are  not  accommodated. 

In  this  paper  we  present  the  first  robust  contribu¬ 
tory  key  agreement  protocols  resilient  to  any  sequence 
of  events  while  preserving  the  group  communication 
membership  and  ordering  guarantees. 

1  Introduction 

The  explosive  growth  of  the  Internet  has  increased 
both  the  number  and  the  popularity  of  applications  that 
require  a  reliable  group  communication  infrastructure, 
such  as  voice-  and  video-conferencing,  white -boards, 
distributed  simulations,  and  replicated  servers  of  all 
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types. 

Secure  group  communication  is  crucial  for  build¬ 
ing  distributed  applications  that  work  in  dynamic  net¬ 
work  environments  and  communicate  over  insecure 
networks  such  as  the  global  Internet.  Key  manage¬ 
ment  is  the  base  for  providing  common  security  ser¬ 
vices  (data  secrecy,  authentication  and  integrity)  for 
group  communication.  There  are  several  approaches 
to  group  key  management. 

One  approach  relies  on  a  single,  centralized  entity, 
to  generate  keys  and  distribute  them  to  the  group.  In 
this  case,  a  so-called  key  server  maintains  long-term 
shared  keys  with  each  group  member  in  order  to  en¬ 
able  secure  two-party  communication  for  the  actual 
key  distribution.  A  specific  form  of  this  solution  uses 
a  fixed  trusted  third  party  (TTP)  as  the  key  server. 
This  approach  has  two  problems:  1)  the  TTP  must  be 
constantly  available  and  2)  a  TTP  must  exist  in  every 
possible  subset  of  a  group  in  order  to  support  contin¬ 
ued  operation  in  the  event  of  network  partitions.  The 
first  problem  can  be  addressed  with  fault-tolerance 
and  replication  techniques.  The  second,  however,  is 
impossible  to  solve  in  a  scalable  and  efficient  man¬ 
ner.  We  note,  however,  that  centralized  approaches 
work  well  in  a  one-to-many  multicast  scenario  since 
a  TTP  (or  a  set  thereof)  placed  at,  or  very  near,  the 
source  of  communication  can  support  continued  oper¬ 
ation  within  an  arbitrary  partition  as  long  as  it  includes 
the  source.  (Typically,  one-to-many  settings  only  aim 
to  offer  continued  operation  within  a  single  partition 
that  includes  the  source;  whereas,  many-to-many  en¬ 
vironments  must  offer  the  same  in  an  arbitrary  number 
of  partitions.) 

Another  key  management  approach  involves  dy¬ 
namically  selecting  -  in  some  deterministic  manner  - 
a  group  member  charged  with  the  task  of  generating 
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keys  and  distributing  them  to  other  group  members. 
This  approach  is  robust  and  more  amenable  to  many- 
to-many  type  of  group  communication  since  any  par¬ 
tition  can  continue  operation  by  electing  a  temporary 
key  server.  The  drawback  here  is  that,  as  in  the  TTP 
case,  a  key  server  must  establish  long-term  pairwise 
secure  channels  with  all  current  group  members  in  or¬ 
der  to  distribute  group  keys.  Consequently,  each  time 
a  new  key  server  comes  into  play,  significant  costs 
must  be  incurred  to  set  up  these  channels.  Another 
disadvantage,  again  as  in  the  TTP  case,  is  the  reliance 
on  a  single  entity  to  generate  good  (i.e.,  cryptographi¬ 
cally  strong,  random)  keys. 

In  contrast  to  the  above,  contributory  key  manage¬ 
ment  asks  each  group  member  to  contribute  an  equal 
share  to  the  common  group  key  (computed  as  a  func¬ 
tion  of  all  members’  contributions).  This  approach 
avoids  the  problems  with  the  single  points  of  trust  and 
failure.  Moreover,  some  contributory  methods  do  not 
require  the  establishment  of  pairwise  secret  channels 
among  group  members.  However,  current  contribu¬ 
tory  key  agreement1  protocols  arc  not  designed  to  tol¬ 
erate  failures  and  group  membership  changes  during 
execution.  In  particular,  nested  (or  cascaded)  failures, 
partitions  and  other  group  events  arc  not  accommo¬ 
dated.  This  is  not  surprising  since  most  multi-round 
cryptographic  protocols  do  not  offer  built-in  robust¬ 
ness  with  the  notable  exception  of  protocols  for  fair 
exchange  [1], 

The  main  goal  of  this  paper  is  to  demonstrate  how 
provably  secure,  multi-round  group  key  agreement 
protocols  can  be  combined  with  reliable  group  com¬ 
munication  services  to  obtain  provably  fault-tolerant 
group  key  agreement  solutions.  More  precisely,  we 
present  two  robust  contributory  key  agreement  pro¬ 
tocols  which  arc  resilient  to  any  sequence  (even  cas¬ 
caded)  of  events  while  preserving  group  communica¬ 
tions  membership  and  ordering  guarantees.  Both  pro¬ 
tocols  are  based  on  Cliques  GDH  contributory  key 
agreement  that  generalizes  on  the  two-party  Diffie- 
Hellman  [2]  key  exchange.  Our  first  protocol  utilizes 
membership  information  provided  by  the  group  com¬ 
munication  system  in  order  to  appropriately  re-start 
Cliques  GDH  key  agreement  in  an  agreed-upon  man- 


1  We  use  the  term  ’’agreement,”  as  opposed  to  ’’distribution”,  to 
emphasize  the  contributory  nature  of  the  key  management. 


ner  every  time  the  group  changes.  The  second  proto¬ 
col  optimizes  the  performance  of  common  cases  at  the 
cost  of  a  more  sophisticated  protocol  state  machine. 

The  rest  of  the  paper  is  organized  as  follows.  The 
remainder  of  this  section  focuses  on  our  motivation  in 
pursuing  this  work  and  overviews  related  work.  We 
then  present  Secure  Spread,  a  secure  group  communi¬ 
cation  system  which  utilizes  our  key  agreement  proto¬ 
cols.  The  two  subsequent  sections  present  two  robust 
key  agreement  protocols  and  prove  their  correctness. 
Finally,  we  summarize  our  work  and  discuss  some  fu¬ 
ture  directions. 

1.1  Motivation 

As  mentioned  earlier,  a  prominent  challenge  en¬ 
countered  in  securing  group  communication  is  in  de¬ 
veloping  robust,  reliable  and  fault-tolerant  group  key 
management  mechanisms  that  perform  well  in  prac¬ 
tice.  While  the  motivation  for  security  services  (key 
management,  in  particular)  in  a  tightly-coupled  group 
communication  setting  is  fairly  intuitive,  the  need  for 
reliable  group  communication  services  by  the  group 
key  management  is  less  obvious.  We  claim  that  re¬ 
liable  and  sequenced  message  delivery  is  important 
(and  even  crucial)  for  cryptographic  group  protocols. 
Asynchronous  network  behavior  must  be  handled  by 
the  underlying  group  communication  layer,  which 
prompts  the  need  for  a  highly  reliable  group  commu¬ 
nication  service. 

This  dependence  is  both  natural  and  mutual.  It 
is  natural  since  secure  dynamic  peer  groups  always 
require  certain  communication  guarantees.  (Best- 
effort  datagram  service  is  not  usually  a  viable  option, 
whereas,  it  may  suffice  for  one-to-many  type  groups 
encountered  in  Internet  multicast  settings.)  It  is  mu¬ 
tual  since  reliable  group  communication  systems  are 
of  limited  utility  in  open  networks  without  strong  se¬ 
curity  services  and  guarantees.  Thus,  we  have  inter¬ 
dependence  among  reliable  group  communication  and 
group  key  management  protocols. 

Cryptographic  protocols  designers  are  primarily 
concerned  with  security  and  typically  assume  that  pro¬ 
tocol  robustness  is  handled  by  the  particular  applica¬ 
tion  or  by  the  underlying  communication  layer.  This  is 
reasonable  in  two-party  protocols  where  communica¬ 
tion  failures  are  relatively  easy  to  handle  and  recover 
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from.  The  picture  changes  dramatically  in  group  pro¬ 
tocols  where  the  behavior  model  is  richer. 

Multi-round  group  key  management  protocols  can¬ 
not  be  expected  to  run  to  completion  without  be¬ 
ing  possibly  interrupted  by  various  group  membership 
events:  joins,  leaves,  disconnects,  partitions,  merges 
or  any  combination  thereof. 

Our  previous  work  [3]  focused  on  the  performance 
evaluation  in  the  scenario  with  no  network  faults  or 
cascaded  events  and  provided  a  good  insight  of  the 
overall  cost  of  high  security  in  a  group  communication 
environment.  The  present  work  goes  into  the  details  of 
a  complete  solution  that  handles  every  possible  combi¬ 
nation  of  group  membership  events.  The  contribution 
of  this  paper,  therefore,  is  the  design,  and  the  proof 
of  correctness  of,  a  robust  contributory  key  agreement 
algorithm. 

1.2  Related  Work 

In  this  section  we  consider  related  work  in  two  ar¬ 
eas:  group  key  management  and  reliable  group  com¬ 
munication. 

1.2.1  Group  Key  Management 

Cryptographic  techniques  for  securing  all  types  of 
multicast-  or  group-based  protocols  require  all  parties 
to  share  a  common  key.  This  requires  a  Group  Key 
Management  (GKM)  protocol  to  provide  methods  for 
generating  new  group  keys  and  updating  existing  keys. 
GKM  protocols  generally  fall  into  two  classes: 

•  Protocols  designed  for  large-scale  (e.g.,  IP  Multi¬ 
cast)  applications  with  a  one-to-many  communi¬ 
cation  paradigm  and  relatively  weak  security  re¬ 
quirements. 

•  Protocols  designed  to  support  tightly-coupled 
dynamic  peer  groups  with  modest  scalability 
requirements,  a  many-to-many  communication 
paradigm  and  strong  security  requirements. 

GKM  protocols  of  the  first  type  arc  being  developed  in 
the  context  of  IETF/IRTF.  One  example  is  the  Group 
Key  Management  Protocol  (GKMP)  [4]  which  pro¬ 
vides  key  dissemination  using  a  dedicated  group  con¬ 
troller.  Another  is  the  Multicast  Key  Management 


Protocol  (MKMP)  [5]  which  assumes  a  number  of 
trusted  “key  distributors”  exist  throughout  the  net¬ 
work.  (MKMP  provides  a  way  for  a  group  member  to 
probe  for  the  nearest  distributor  in  order  to  get  a  copy 
of  a  group  key.)  Some  GKM  protocols  leverage  off 
particular  IP  Multicast  routing  protocols.  The  Scal¬ 
able  Multicast  Key  Distribution  [6]  approach  uses  the 
Core  Based  Trees  [7]  multicast  routing  protocol  state 
and  structure  to  authorize  members  and  disseminate 
keys.  Although  it  provides  an  efficient  method  of  key 
dissemination,  this  method  is  limited  to  domains  that 
use  CBT  for  multicast  routing. 

Some  key  management  approaches  targeting  IP 
Multicast  use  hierarchical  key  distribution.  For  exam¬ 
ple,  the  Iolus  system  [8],  partitions  the  multicast  tree 
into  subgroups;  each  sub-group  has  a  different  group 
key  and  nodes  on  the  borders  of  sub-groups  perform 
re-encryption  of  multicast  data  in  real  time.  The  work 
of  [9]  and  the  Intra-domain  Group  Key  Management 
Protocol  advance  this  concept  by  allowing  each  sub¬ 
group  to  be  a  separate  domain  with  independent  con¬ 
trol  over  what  group  keying  protocol  is  used.  Another 
hierarchical  approach  makes  the  group  key  itself  hier¬ 
archical,  usually  with  a  tree-based  structure.  In  [10], 
a  tree-oriented  key  structure  allows  each  leaf  to  repre¬ 
sent  a  number  of  nodes  and  some  membership  changes 
to  only  require  log(n)  key  changes. 

A  number  of  GKM  protocols  supporting  abstract 
peer  groups  have  been  developed  in  the  last  decade 
[1 1],  [12],  [13],  [14],  [15],  [16],  [17].  All,  except  [17], 
extend  the  well-known  Diffie-Hellman  key  exchange 
[2]  method  to  group  of  n  parties.  These  protocols 
vary  in  degrees  of  protection  from  hostile  attacks  and 
in  their  performance  characteristics.  (For  an  in-depth 
comparison,  see  [16].)  In  this  paper,  we  make  use 
of  the  CFIQUES  toolkit  which  implements  -  among 
other  methods  -  a  suite  of  protocols,  called  generic 
Group  Diffie-Hellman  (GDH).  GDH  offers  contribu¬ 
tory  authenticated  group  key  agreement  and  handles 
dynamic  membership  changes  [15,  16].  The  entire 
protocol  suite  has  been  proven  secure  with  respect  to 
both  passive  and  active  attacks. 

1.2.2  Reliable  Group  Communication 

Reliable  group  communication  in  FAN  environments 
have  a  well-developed  history  beginning  with  ISIS 


[18],  and  more  recent  systems  such  as  Transis  [19], 
Horus  [20],  Totem  [21],  and  RMP  [22].  These  systems 
explored  several  different  models  of  Group  Commu¬ 
nication  such  as  Virtual  Synchrony  [23]  and  Extended 
Virtual  Synchrony  [24],  More  recent  work  in  this  area 
focuses  on  scaling  group  membership  to  wide-area 
networks  [25],  [26]. 

Research  in  securing  group  communication  is  fairly 
new.  The  only  actual  implementations  of  group  com¬ 
munication  systems  that  focus  on  security  (in  addition 
to  ours),  arc  SecureRing  [27]  project  at  UCSB,  and 
the  Horus/Ensemble  work  at  Cornell  [28].  The  Se¬ 
cureRing  system  protects  a  low-level  ring  protocol  by 
using  cryptographic  techniques  to  authenticate  each 
transmission  of  the  token  and  each  data  message  re¬ 
ceived.  The  Ensemble  security  work  is  the  state-of- 
the-art  in  secure  reliable  group  communication  and 
addresses  problems  as  group  keys  and  re -keying.  It 
also  allows  application-dependent  trust  models  and 
optimizes  certain  aspects  of  group  key  generation  and 
distribution  protocols.  In  comparison  with  our  ap¬ 
proach,  Ensemble  uses  a  different  group  key  structure 
that  is  not  contributory  and  provides  a  different  set  of 
security  guarantees. 

Recent  research  on  Bimodal-Multicast,  Gossip- 
based  protocols  [29]  and  the  Spinglass  system  has 
largely  focused  on  increasing  the  scalability  and  sta¬ 
bility  of  reliable  group  communication  services  in 
more  hostile  environments  such  as  wide-area  and 
lossy  networks  by  providing  probabilistic  guarantees 
about  delivery,  reliability,  and  membership. 

2  A  Secure  Group  Communication  Environ¬ 
ment 

The  work  discussed  in  this  paper  has  involved  in¬ 
tegrating  the  Spread  wide-area  group  communication 
system  with  the  group  key  agreement  protocols  in 
the  Cliques  GDH  protocol  suite.  In  this  section  we 
overview  both  Spread  and  Cliques  toolkits. 

2.1  Spread  Toolkit 

Spread  [30],  [31]  is  a  group  communication  system 
for  wide  and  local  area  networks.  It  provides  all  the 
services  of  traditional  group  communication  systems, 
including:  unreliable/reliable  delivery,  FIFO,  causal. 


total  ordering,  and  membership  services  with  strong 
semantics. 

Spread  creates  an  overlay  network  that  can  im¬ 
pose  an  arbitrary  network  configuration  (such  as  point  - 
to-multi-point,  tree,  ring,  tree-with-subgroups  or  any 
combination  thereof)  to  adapt  the  system  to  different 
network  environments.  The  Spread  architecture  al¬ 
lows  multiple  protocols  to  be  used  on  links  both  be¬ 
tween  and  within  sites.  The  Spread  toolkit  is  very  use¬ 
ful  for  applications  that  need  traditional  group  com¬ 
munication  services  (such  as  causal  and  total  ordering, 
membership  and  delivery  guarantees)  but  also  need  to 
operate  over  w  ide-area  networks. 

The  system  consists  of  a  long-running  daemon  and 
a  library  linked  with  the  application.  This  architec¬ 
ture  has  many  benefits,  the  most  important  for  wide- 
area  settings  being  the  ability  to  pay  the  minimum 
possible  price  for  different  causes  of  group  member¬ 
ship  changes.  A  simple  join  or  leave  of  a  process 
translates  into  a  single  message,  while  a  daemon  dis¬ 
connection  or  connection  requires  a  full  membership 
change.  Luckily,  there  is  a  strong  inverse  relationship 
between  the  frequency  of  these  events  and  their  cost  in 
a  practical  system.  The  process  and  daemon  member¬ 
ships  correspond  to  the  more  common  model  of  light¬ 
weight  and  heavy-weight  groups. 

Spread  scales  well  with  the  number  of  groups  used 
by  the  application  without  imposing  any  overhead  on 
network  routers.  Group  naming  and  addressing  is  not 
a  shared  resource  (as  in  IP  multicast  addressing)  but 
rather  a  large  space  of  strings  which  is  unique  to  a  col¬ 
laboration  session. 

The  toolkit  can  support  a  large  number  of  differ¬ 
ent  collaboration  sessions,  each  of  which  spans  the 
Internet  but  has  only  a  moderate  number  of  partici¬ 
pants.  This  is  achieved  by  using  unicast  messages  over 
the  w  ide-area  network,  routing  them  between  Spread 
nodes  on  the  overlay  network. 

The  Spread  system  provides  two  different  seman¬ 
tics:  Extended  Virtual  Synchrony  [24,  32]  and  View 
Synchrony  [33].  In  this  paper,  and  for  our  implemen¬ 
tation  we  only  use  the  View  Synchrony  semantics  of 
Spread. 

The  Spread  toolkit  is  available  publicly  and  is  be¬ 
ing  used  by  several  organizations  for  both  research  and 
practical  projects.  The  toolkit  supports  cross-platform 
applications  and  has  been  ported  to  several  Unix  plat- 
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forms  as  well  as  Windows  and  Java  environments. 

2.2  Cliques  Toolkit 

Cliques  [16,  15,  34]  is  a  cryptographic  toolkit  pro¬ 
viding  key  management  services  for  dynamic  peer 
groups.  Cliques  includes  several  protocol  suites: 

•  GDH:  based  on  group  extensions  of  the  2-party 
Diffie-Hellman  key  exchange  [15,  16];  provides 
fully  contributory  authenticated  key  agreement. 
GDH  is  fairly  computation-intensive  requiring 
O(n)  cryptographic  operations  upon  each  key 
change.  It  is,  however,  bandwidth-efficient. 

•  CKD:  centralized  key  distribution  with  the  key 
server  dynamically  chosen  from  among  the  group 
members.  A  key  server  uses  pairwise  Diffie- 
Hellman  key  exchange  to  distribute  keys.  CKD 
is  comparable  to  GDH  in  terms  of  both  computa¬ 
tion  and  bandwidth  costs. 

•  TGDH:  tree-based  group  Diffie-Hellman  [34]; 
TGDH  is  more  efficient  than  the  above  in 
terms  of  computation  as  most  operations  require 
O(logn)  cryptographic  operations.  (The  security 
of  TGDH  is  slightly  weaker  and  it  lacks  several 
other  features  not  germane  in  this  context.) 

•  BD:  a  protocol  based  on  Burmester-Desmedt 
[13]  variation  of  group  Diffie-Hellman.  BD  is 
computation-efficient  requiring  constant  number 
of  exponentiations  upon  any  key  change.  How¬ 
ever,  communication  costs  arc  significant  with 
two  rounds  of  n-to-n  broadcasts. 

All  Cliques  protocol  suites  offer  key  independence, 
perfect  forward  secrecy  and  resistance  to  known  key 
attacks.  (See  [35,  16]  for  precise  definitions  of  these 
properties.) 

In  this  paper,  we  focus  only  on  the  GDH  protocol 
suite  within  the  Cliques  toolkit.  As  mentioned  ear¬ 
lier,  our  specific  goal  is  to  take  a  provably  secure, 
multi-round  group  key  agreement  protocol  (GDH) 
and,  by  combining  it  with  the  reliable  group  com¬ 
munication  service  (Spread),  obtain  a  provably  fault- 
tolerant  group  key  agreement  solution. 

Cliques  GDH  API  [36]  is  the  implementation  of 
the  GDH  protocol  suite.  It  contains  GDH  crypto¬ 
graphic  primitives  while  assuming  the  existence  of  a 


reliable  communication  platform  for  transporting  pro¬ 
tocol  messages.  GDH  assigns  a  special  role  to  the  last 
member  to  join  a  group.  This  role,  referred  to  as  the 
group  controller,  floats  as  group  membership  changes. 
A  group  controller  is  charged  with  initiating  key  up¬ 
dates  following  membership  changes.2  The  following 
operations  trigger  a  key  update: 

•  join:  add  a  single  new  member  to  the  group  (han¬ 
dled  as  a  special  case  of  merge). 

•  merge:  add  multiple  members  to  the  group. 

•  leave:  one  member  voluntarily  leaves  the  group 
(handled  as  a  special  case  of  partition). 

•  partition:  multiple  members  leave  the  group  due 
to  expulsion  or  a  network  event. 

3  System  Model 

In  this  section  we  specify  the  failure  and  the  group 
communication  models  used  in  this  paper. 

3.1  Failure  Model 

We  consider  a  distributed  system ,  a  group  of  pro¬ 
cesses  executing  on  one  or  more  computers  and  coor¬ 
dinating  actions  by  exchanging  messages  ([37]).  The 
message  exchange  is  achieved  via  asynchronous  mul¬ 
ticast  and  unicast  messages.  Messages  can  be  lost. 

The  system  is  subject  to  process  crashes  and  recov¬ 
eries.  A  crash  of  any  component  of  the  process  such 
as  the  key-agreement  layer,  the  Cliques  library,  or  the 
group  communication  system  is  considered  a  process 
crash.  It  is  assumed  that  the  crash  of  one  of  these  com¬ 
ponents  is  detected  by  all  the  other  components  and  is 
treated  as  a  process  crash. 

Also,  the  system  is  prone  to  partitions  which  may 
result  a  network  being  split  into  disconnected  sub¬ 
networks.  When  such  a  partition  is  fixed,  the  dis¬ 
connected  components  merge  into  a  larger  connected 
component.  While  processes  arc  in  separate  discon¬ 
nected  components  they  cannot  exchange  messages. 

We  assume  that  message  corruption  is  masked  by  a 
lower  layer.  Byzantine  failures  arc  not  considered. 

2GDH  API  also  allows  a  key  refresh  operation  which  may  be 
initiated  only  by  the  current  controller. 
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Our  intruder  model  takes  into  account  only  outside 
intruders,  both  passive  and  active.  An  outsider  is  any¬ 
one  who  is  not  a  current  group  member.  (Of  course, 
any  former  and  future  member,  is  an  outsider  accord¬ 
ing  to  this  definition.)  We  do  not  consider  insider  at¬ 
tacks  since  our  threat  model  concentrates  on  the  se¬ 
crecy  of  group  keys  and  the  integrity  of  the  group 
membership  (i.e.,  the  inability  to  spoof  authenticated 
membership).  Consequently,  insider  attacks  arc  not 
relevant  because  a  malicious  insider  can  always  reveal 
the  group  key  and/or  its  own  private  key  thus  allowing 
for  fraudulent  membership  authentication. 

Passive  outsider  attacks  involve  eavesdropping  with 
the  aim  of  discovering  the  group  key(s).  This  attack 
type  has  been  proven  to  be  computationally  infeasi¬ 
ble  in  [15].  Active  outsider  attacks  involve  injecting, 
deleting,  delaying  and  modifying  protocol  messages. 
Some  of  these  attacks  aim  to  cause  denial  of  service; 
we  do  not  address  these  denial  of  service  attacks.  At¬ 
tacks  with  the  goal  of  impersonating  a  group  member 
are  prevented  by  the  use  of  public  key-based  signa¬ 
tures.  (All  protocol  messages  arc  signed  by  the  sender 
and  verified  by  all  receivers.)  Other,  more  subtle,  ac¬ 
tive  attacks  aim  to  introduce  a  known  (to  the  attacker) 
or  old  key.  These  arc  prevented  by  the  combined  use 
of:  timestamps,  unique  protocol  message  identifiers 
and  sequence  numbers  (identifying  the  particular  pro¬ 
tocol  run)  in  each  protocol  message. 

3.2  Group  Communication  Model 

A  group  communication  system  usually  provides 
fundamental  services  such  as  membership  as  well  as 
dissemination,  reliability  and  ordering  of  messages. 
The  membership  service  notifies  the  upper-level  ap¬ 
plication  with  a  list  of  group  members  each  time  the 
group  changes.  This  notification-of-membership  ser¬ 
vice  is  called  a  view.  Every  process  that  is  paid  of  the 
group  communication  system  runs  the  membership  al¬ 
gorithm  and  decides  on  the  new  view  in  agreement 
with  other  connected  processes.  Once  this  decision 
is  made,  the  view  is  installed  and  the  upper-level  ap¬ 
plication  is  notified. 

Several  different  sets  of  membership  properties 
have  been  defined  in  the  literature.  Each  provides  a 
different  set  of  semantic  guarantees  to  the  application, 
and  are  usually  called  Virtual  Synchrony  semantics  or 


some  valiant  on  the  name.  The  many  variations  of 
virtual  synchrony  are  all  based  on  the  property  that 
processes  moving  together  from  one  view  to  another 
deliver  the  same  set  of  messages  in  the  former  mem¬ 
bership  view. 

Some  group  communication  systems  have  been 
built  [20],  [22],  [26]  that  approximate  the  virtual  syn¬ 
chrony  model  along  with  some  related  properties. 
However,  each  system  does  not  provide  the  exact  same 
set  of  properties,  and  to  the  best  of  our  knowledge  a 
canonical  “Virtual  Synchrony  model”  of  an  entire  sys¬ 
tem  has  not  been  defined  in  the  literature.  A  good 
survey  describing  many  of  the  variations  of  differ¬ 
ent  properties  for  virtual  synchrony  semantics  can  be 
found  in  [38]. 

Virtual  synchrony  strengthens  the  shared  state  of 
the  system  by  delivering  messages  in  the  same  mem¬ 
bership  as  they  were  sent  in.  This  enables  the  use 
of  a  shared  key  to  encrypt  data,  since  the  receiver  is 
guaranteed  to  have  the  same  membership  view  as  the 
sender  and  therefore  the  same  key  (ignoring  for  now 
some  constraints  on  rekeying). 

This  work  assumes  that  the  group  communication 
system  supports  virtual  synchrony  semantics  as  they 
are  defined  below.  The  description  of  the  properties  is 
largely  based  on  the  survey  [38]  and  the  description  of 
the  Extended  Virtual  Synchrony  semantics  [24]. 

Note  that  we  define  that  some  event  occurred  in 
view  v  at  process  p  if  the  most  recent  view  installed 
by  process  p  was  v. 

1.  Self  Inclusion 

If  process  p  installs  a  view  v  then  p  is  a  member 
of  v. 

2.  Local  Monotonicity 

If  process  p  installs  a  view  v  after  installing  a 
view  v'  then  the  identifier  id  of  v  is  greater  than 
the  identifier  id'  of  v' . 

3.  Sending  View  Delivery 

A  message  is  delivered  in  the  view  that  it  was  sent 
in. 

4.  Delivery  Integrity 

If  process  p  delivers  a  message  m  in  a  view  v, 
then  there  exists  a  process  q  that  sent  m  in  v 
causally  before  p  delivered  m. 
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5.  No  Duplication 

A  message  is  not  sent  twice.  A  message  is  not 
delivered  twice  to  the  same  process. 

6.  Seif  Delivery: 

If  process  p  sends  a  message  m,  then  p  delivers 
m  unless  it  crashes. 

7.  Transitional  Set 

1)  If  two  processes  p  and  q  install  the  same  view, 
and  q  is  included  in  p’s  transitional  set  for  this 
view  then  p’s  previous  view  was  identical  to  q’s 
previous  view. 

2)  If  two  processes  p  and  q  install  the  same  view, 
and  q  is  included  in  p’s  transitional  set  for  this 
view  then  p  is  included  in  q’s  transitional  set  for 
this  view. 

8.  Virtual  Synchrony 

Two  processes  that  move  together3  through  two 
consecutive  views  deliver  the  same  set  of  mes¬ 
sages  in  the  former. 

9.  Causal  Delivery 

If  message  m  causally  precedes  message  mV  and 
both  arc  sent  in  the  same  view,  then  any  process 
q  that  delivers  m'  delivers  m  before  mV 

10.  Agreed  Delivery 

1)  Agreed  delivery  maintains  causal  delivery 
guarantees. 

2)  If  agreed  messages  m  and  m!  arc  delivered  at 
process  p  in  this  order,  and  m  and  m'  arc  deliv¬ 
ered  by  process  q.  then  m!  is  delivered  by  q  after 
it  delivers  m. 

3)  If  agreed  messages  m  and  m'  arc  delivered  by 
process  p  in  view  v  in  this  order,  and  m!  is  deliv¬ 
ered  by  process  q  in  v  before  a  transitional  signal, 
then  q  delivers  m.  If  messages  m  and  m!  arc  de¬ 
livered  by  process  p  in  view  v  in  this  order,  and 
m!  is  delivered  by  process  q  in  v  after  a  transi¬ 
tional  signal,  then  q  delivers  m  if  r,  the  sender  of 
m,  belongs  to  q’s  transitional  set. 

11.  Safe  Delivery 

1)  Safe  delivery  maintains  agreed  delivery  guar¬ 
antees. 

3If  process  p  installs  a  view  v  with  process  q  in  its  transitional 
set  and  process  q  installs  v  as  well,  then  p  and  q  are  said  to  move 
together. 


2)  If  process  p  delivers  a  safe  message  m  in  view 
v  before  the  transitional  signal,  then  every  pro¬ 
cess  q  of  view  v  delivers  m  unless  it  crashes.  If 
process  p  delivers  a  safe  message  m  in  view  v 
after  the  transitional  signal,  then  every  process  q 
that  belongs  to  p’s  transitional  set  delivers  m  af¬ 
ter  the  transitional  signal  unless  it  crashes. 

4  A  Basic  Robust  Algorithm 

This  section  discusses  the  details  of  a  basic  robust 
key  agreement  algorithm.  We  describe  the  algorithm 
and  prove  its  correctness,  i.e.  that  the  algorithm  pre¬ 
serves  the  virtual  synchrony  semantics  presented  in 
Section  3.2.  Throughout  the  remainder  of  the  paper, 
we  mean  by  the  group  communication  system  (GCS), 
a  group  communication  system  providing  the  virtual 
synchrony  semantics. 

4.1  Algorithm  Description 

Our  basic  algorithm  is  based  on  the  Cliques  GDH 
IKA.2  protocol.  Briefly,  this  protocol  works  as  follows 
(see  [15]  for  a  complete  description): 

When  an  additive  group  view  change  happens  (a 
join  or  a  merge)  the  current  group  controller  gener¬ 
ates  a  new  key  token  by  refreshing  its  contribution  to 
the  group  key  and  passes  the  token  to  one  of  the  new 
members.  When  that  new  member  receives  this  token, 
it  adds  its  own  contribution  and  passes  the  token  to  the 
next  new  member4.  Eventually,  the  token  reaches  the 
last  new  member.  This  new  member,  who  is  slated  to 
become  the  new  group  controller,  broadcasts  the  token 
to  the  group  without  adding  its  contribution.  Upon  re¬ 
ceiving  the  broadcast  token,  each  group  member  (old 
and  new)  factors  out  its  contribution  and  unicasts  the 
result  (called  a  factor-out  token)  to  the  new  controller. 
The  new  controller  collects  all  the  factor-out  tokens, 
adds  its  own  contribution  to  each  of  them,  builds  a 
list  of  partial  keys  and  broadcasts  the  list  to  the  group. 
Every  member  can  then  obtain  the  group  key  by  fac¬ 
toring  in  its  contribution.  (This  is  actually  performed 
with  modular  exponentiation.) 

4The  new  member  list  and  its  ordering  is  decided  by  the  un¬ 
derlying  group  communication  system;  Spread  in  our  case.  The 
actual  order  is  irrelevant  to  Cliques. 
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When  some  members  leave  the  group,  the  group 
controller  (who,  at  all  times,  is  the  most  recent  group 
member)  removes  their  corresponding  partial  keys 
from  the  list  of  partial  keys,  refreshes  each  part ial  key 
in  the  list  and  broadcasts  the  list  to  the  group.  Each 
remaining  member  can  then  compute  the  shared  key. 

The  algorithm  described  above  is  secure  and  cor¬ 
rect.  Security  is  preserved  independently  of  any  se¬ 
quence  of  membership  events,  while  correctness  holds 
only  as  long  as  no  additional  group  view  change  takes 
place  before  the  protocol  terminates. 

To  elaborate  on  this  claim,  consider  what  happens 
if  a  subtractive  (leave  or  partition)  group  membership 
event  occurs  while  the  above  protocol  is  in  progress, 
for  example,  while  the  group  controller  is  waiting  for 
individual  unicasts  from  all  group  members.  Since 
the  Cliques  protocol  is  unaware  of  the  membership 
change  (which  is  ’’visible”  only  to  the  group  commu¬ 
nication  system),  the  group  controller  will  not  proceed 
until  all  factor-out  tokens  (including  those  from  for¬ 
mer  members)  arc  collected.  Therefore,  the  system 
will  block.  Similar  scenarios  are  also  possible,  e.g.,  if 
one  of  the  new  members  crashes  while  adding  its  con¬ 
tribution  to  a  group  key.  In  this  case,  the  token  will 
never  reach  the  new  group  controller  and  the  protocol 
will,  once  again,  simply  block. 

If  the  nested  event  is  additive  (join  or  merge),  the 
protocol  operates  correctly.  In  other  words,  it  runs  to 
completion  and  the  nested  event  is  handled  serially. 
(We  note,  however,  that  this  is  not  optimal  since,  ide¬ 
ally,  multiple  additive  events  can  be  ’’chained”  effec¬ 
tively  reducing  broadcasts  and  factor-out  token  implo¬ 
sions.) 

As  the  above  examples  illustrate,  the  protocol  does 
not  function  correctly  in  the  face  of  cascaded  subtrac¬ 
tive  membership  events.  This  behavior  is  not  accept¬ 
able  for  reliable  group  communication  systems  that 
aim  to  provide  a  high  degree  of  robustness  and  fault- 
tolerance. 

A  natural  and  correct  solution  to  this  problem  is  as 
follows:  every  time  a  group  view  change  occurs,  the 
group  deterministically  chooses  a  member  (say,  the 
oldest)  and  runs  the  Cliques  GDH  protocol  with  the 
chosen  member  initializing  it.  Note  that  this  approach 
costs  twice  in  computation  and  0(n )  more  in  the  num¬ 
ber  of  messages  for  the  common  case  with  no  cascad¬ 
ing  membership  events.  This  will  be  rectified  in  the 


Figure  1.  Secure  group  communication 
model 


second  protocol  described  in  Section  5. 

When  the  key-agreement  protocol  is  integrated  with 
a  group  communication  system  and  virtual  synchrony 
semantics  must  be  preserved,  extra  care  must  be 
taken  in  order  to  provide  all  its  guarantees  to  the 
application,  including  delivery  of  the  correct  views, 
transitional  signal  and  transitional  sets.  We  will 
elaborate  on  these  issues  later.  Figure  1  presents 
the  architecture  of  a  secure  group  communication 
system.  The  system  uses  the  following  types  of 
messages:  Cliques  messages  (final_token_msg,  par- 
tial_token_msg,  keyJist_msg,  fact_out_msg),  which 
arc  specific  to  the  key  agreement  protocol  (see  [36]); 
membership  notification  messages  (memb_msg);  tran¬ 
sitional  signal  messages  (trans_signal_msg);  applica¬ 
tion  messages  (data_msg);  flush  mechanism  messages 
(flush_rcqucst_msg,  flush_ok_msg). 

To  satisfy  Sending  View  Delivery  without  discard¬ 
ing  messages  from  live  and  connected  members,  a 
group  communication  system  must  block  the  send¬ 
ing  of  messages  before  the  new  membership  is  in¬ 
stalled.  In  order  to  implement  Sending  View  Deliv¬ 
ery  the  group  communication  system  sends  a  message 
(llush_rcqucst_nisg)  to  the  client  asking  for  permission 
to  install  a  new  membership  before  actually  creating 
the  membership.  The  application  responds  with  an 
acknowledgement  message  (flush_ok_msg)  which  fol- 


lows  all  the  messages  sent  by  the  application  in  the 
old  view.  After  sending  the  acknowledgement  mes¬ 
sage,  the  application  is  not  allowed  to  send  any  mes¬ 
sages  until  the  new  view  is  delivered.  In  Figure  1 ,  the 
key-agreement  algorithm  interacts  with  both  the  appli¬ 
cation  and  GCS.  The  key-agreement  algorithm  imple¬ 
ments  the  blocking  mechanism  transparently.  When 
a  llush_rcquest_msg  message  is  received  from  GCS,  it 
is  delivered  to  the  user  application.  When  the  appli¬ 
cation  acknowledgement  message  is  received  it  is  sent 
down  to  GCS. 

A  process  starts  executing  the  algorithm  by  invok¬ 
ing  the  join  primitive  of  the  key-agreement  module 
which  translates  into  a  group  communication  join  call. 
In  any  state  of  the  algorithm  a  process  can  voluntar¬ 
ily  leave  by  invoking  the  leave  primitive  of  the  key- 
agreement  module  which  translates  it  into  a  group 
communication  leave  call. 

The  specification  of  the  algorithm  is  defined  in 
terms  of  the  following  received  events  which  are  as¬ 
sociated  with  a  specific  group: 

•  PartiaLToken:  a  partial  token  message  (par- 

tial_token_msg)  was  received  by  the  key- 

agreement  algorithm  from  the  GCS. 

•  FinaLToken:  a  final  token  message  (fi- 

nal_token_msg)  was  received  by  the  key- 

agreement  algorithm  from  the  GCS. 

•  Fact_Out:  a  factor  out  message  (factor_out_msg) 
was  received  by  the  key-agreement  algorithm 
from  the  GCS. 


•  TransitionaLSignal:  a  transitional  signal  mes¬ 
sage  (trans_signal_msg)  was  received  by  the  key- 
agreement  algorithm  from  the  GCS. 

•  Membership:  a  membership  message 

(memb_msg)  was  received  by  the  key-agreement 
algorithm  from  the  GCS. 

•  Flush_Request:  a  flush  request  message 

(flush_rcquest_msg)  was  received  by  the  key- 
agreement  algorithm  from  the  GCS. 

•  Secure_Flush_Request:  a  flush  request  message 
(flush_rcqucst_msg)  was  received  by  the  applica¬ 
tion  from  the  key-agreement  algorithm. 

•  Secure_Flush_Ok:  a  flush  acknowledge  mes¬ 
sage  (flush_ok_msg)  was  received  by  the  key- 
agreement  algorithm  from  the  application. 

Note  that  the  same  type  of  message  can  be  associ¬ 
ated  with  different  events,  depending  on  the  source 
of  the  message.  For  example,  both  Flush_Request 
and  Secure_Flush_Request  events  are  associated  with 
a  llush_rcqucst_msg  message,  but  in  the  first  case  the 
message  is  received  by  the  key-agreement  algorithm 
from  the  application,  while  in  the  second  case  the 
message  is  received  by  the  application  from  the  key- 
agreement  algorithm. 

The  algorithm  consists  of  a  state  machine  having 
the  following  states: 

•  SECURE  (S):  in  this  state  the  secure  group  is 
functional,  all  of  the  members  have  the  group 
key  and  can  communicate  securely;  the  pos¬ 


Key_List:  a  key  list  message  (key_list_msg)  was 
received  by  the  key-agreement  algorithm  from 
the  GCS. 

User_Message:  a  data  application  message 
(data_msg)  was  received  by  the  key-agreement 
algorithm  from  the  application.  The  user  can 
send  messages  using  broadcast  or  unicast  ser¬ 
vices. 

DataJVIessage:  a  data  application  message 
(data_msg)  was  received  by  the  key-agreement 
algorithm  from  the  GCS. 


sible  events  are  Data_Message,  User_Message, 
Secure_Flush_Ok,  Flush_Request,  and  Transi¬ 
tionaLSignal;  getting  a  Secure_Flush_Ok  with¬ 
out  receiving  a  Flush_Request  is  illegal;  all  other 
events  are  not  possible. 

•  WAIT_FOR_PARTIAL_TOKEN  (PT):  in 

this  state  the  process  is  waiting  for  a  par- 
tial_token_msg  message;  the  possible  events 
are  PartiaLToken,  Flush_Request  and  Tran¬ 
sitionaLSignal;  User_Message  and  Se- 
cure_Flush_Ok  are  illegal;  all  other  events 
are  not  possible. 
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•  WAIT _FOR_FINAL_TOKEN  (FT):  in  this  state 
the  process  is  waiting  for  a  final_token_msg  mes¬ 
sage;  the  possible  events  are  FinaLToken, 
Flush_Request  and  TransitionaLSignal; 
UserJVIessage  and  Secure_Flush_Ok  are  il¬ 
legal;  all  other  events  arc  possible. 

•  COLLECT _FACT_OUTS  (FO):  in  this  state  the 
process  is  waiting  for  N  —  1  fact_out_msg  mes¬ 
sages  (where  N  is  the  size  of  the  group);  the  only 
possible  events  are  Fact_Out,  Flush_Request, 
and  TransitionaLSignal;  UserJVIessage  and  Se¬ 
cure  Jdush_Ok  are  illegal;  all  other  events  are  not 
possible. 

•  WAIT _FOR_KEY _LIST  (KL):  in  this  state  the 
process  is  waiting  for  a  keyJist_msg  message; 
the  possible  events  arc  KcyJJst,  Flush_Request 
and  TransitionaLSignal;  UserJVIessage  and  Se¬ 
cure  _Flush_Ok  are  illegal;  all  other  events  are  not 
possible. 

•  WAIT_FOR_CASCADINGJMEMBERSHIP 
(CM):  in  this  state  the  process  is  waiting  for  arc 
membership  and  transitional  signal  messages 
(memb_msg  and  trans_signal_msg);  the  possible 
events  arc  Membership,  TransitionaLSignal, 
DataJVIessage  (possible  only  the  first  time 
the  process  gets  in  this  state),  PartiaLToken, 
FinaLToken,  Fact_Out  and  KcyJJst  (they  cor¬ 
respond  to  Cliques  messages  from  a  previous 
instance  of  the  key  agreement  protocol  when 
cascaded  events  happen);  UserJVIessage  and 
Secure_Flush_Ok  arc  illegal;  all  other  events  arc 
not  possible. 

A  process  handles  an  event  by  performing  two 
types  of  actions.  The  first  type  of  action  is 
a  group  communication  operation  and  can  be  ei¬ 
ther  a  message  delivery,  or  a  message  send  such 
as  unicast,  broadcast,  or  sendJlush_ok.  The  sec¬ 
ond  type  of  action  is  a  key  agreement  specific 
action.  This  translates  into  either  computation 
(clq_first_member,  clq_new_member,  clq_update_ctx, 
clq_update_key,  clq_factor_out,  clqjvicrge)  or  ac¬ 
cess  to  Cliques  state  information  (clq_destroy_ctx, 
clq_get_secret,  clq_new_gc,  clq_next_member).  These 
primitives  are  part  of  the  Cliques  GDH  API  specifica¬ 


tion  and  are  described  in  detail  in  [36] .  We  make  use 
of  a  few  trivial  procedures: 

•  alone:  given  a  membership  notification  for  a 
group,  which  contains  a  list  of  all  members  of 
a  group,  it  returns  TRUE  if  the  process  invoking 
it  is  the  only  member  of  the  group,  FALSE  other¬ 
wise; 

•  ready:  given  a  key  Jist  message,  it  returns  TRUE 
when  the  list  is  ready  to  be  broadcast,  FALSE 
otherwise; 

•  last:  given  a  Clq_ctx  and  a  name  of  a  process,  it 
returns  TRUE  if  the  process  is  the  last  one  on  the 
Cliques  list,  FALSE  otherwise; 

•  isJn:  given  an  item  and  a  set,  returns  TRUE  if 
the  set  contains  the  item,  FALSE  otherwise; 

•  empty:  given  a  set,  returns  TRUE  if  the  set  is 
empty,  FALSE  otherwise; 

•  choose:  given  a  set,  deterministically  choose  a 
member  and  returns  that  member; 

•  -:  this  is  the  subtraction  operator  for  sets; 

We  also  make  use  of  some  important  data  structures. 
The  Membership  data  structure  keeps  information  re¬ 
garding  a  membership  notification: 

•  mbJd ,  the  unique  identifier  of  the  view; 

•  mb_set,  the  set  of  all  the  members  of  this  view; 

•  vsjset ,  the  transitional  set  associated  with  this  no¬ 
tification; 

•  me  rye  set,  the  members  from  the  new  view  that 
are  not  in  the  transitional  set  of  the  new  view; 

•  leaveset,  the  members  from  the  previous  view 
that  are  not  in  the  transitional  set  of  the  new  view. 

Group  communication  systems  usually  provide  only 
the  first  three  pieces  of  information  in  a  membership 
notification.  By  using  the  membership  set  of  the  pre¬ 
vious  membership  notification,  and  the  current  mem¬ 
bership  notification,  the  merge_set  and  leave_set  can 
be  computed  by  either  the  key-agreement  algorithm  or 


10 


New_membership . vs_set  :=  EMPTY 
New_membership .  mb_set  :=  Me 
New_membership.merge_set  :=  EMPTY 
New_membership . leave_set  : =  EMPTY 
New_membership . mb_id  : =  0 
First_transitional  :=  TRUE 
VS_transitional  :=  FALSE 
First_cascaded_membership  :=  TRUE 
Wait_for_sec_f lush_ok  :=  FALSE 
KL_got_f lush_req  :=  FALSE 
Event  : =  NULL 
Clq_ctx  :=  NULL 
Group_key  : =  NULL 

Figure  3.  Initialization  of  global  variables 

the  GCS.  To  simplify  the  presentation  of  the  pseudo¬ 
code  of  the  algorithm  we  assume  that  the  merge  set 
and  leave  set  are  provided  by  the  group  communica¬ 
tion  system  as  paid  of  the  membership  notification. 
The  Cliques-ctx  data  structure  is  paid  of  the  Cliques 
GDH  API  specification,  described  in  [36]. 

Every  process  executes  the  algorithm  for  a  spe¬ 
cific  group  and  maintains  a  list  of  global  variables. 
Group -name  is  the  name  of  the  group  for  which 
the  algorithm  is  executed.  Group Jcey  is  the  shared 
secret  of  the  group,  while  Me  is  the  process  exe¬ 
cuting  the  algorithm.  The  Event  variable  represents 
the  current  event  handled.  Clq-dx  keeps  all  the 
cryptographic  context  required  by  the  Cliques  API. 
New  .Membership  is  the  new  membership  that  will 
be  delivered,  and  VSset  is  used  to  compute  the 
transitional  set  delivered  to  the  application  with  a  new 
membership.  Five  global  boolean  variables  arc  used 
in  order  to  facilitate  the  updating  of  the  VS_set  vari¬ 
able,  the  transitional  signal  delivery,  the  correctness 
of  the  Secure_Flush_Ok  events  and  the  delivery  of 
secure  membership  notifications:  First-transitional, 
First-cascadedjnembership,  Wait  -for  sec  -fl-ok, 

VS -transitional  and  KL_got  Jiush-reg . 

All  global  variables  arc  written  with  capital  letter, 
while  all  other  variables  are  assumed  to  be  local.  Fig¬ 
ure  3  shows  the  initialization  of  the  global  variables. 

A  diagram  of  the  state  machine  is  presented  in  Fig¬ 
ure  2  and  the  corresponding  pseudo-code  in  Figures  4, 
5,6,7,  8,  9. 

4.2  Correctness  Proof 

In  this  section  we  prove  that  the  basic  robust  al¬ 
gorithm  preserves  the  Virtual  Synchrony  Model  de¬ 
scribed  in  Section  3.2.  We  assume  that  the  underlying 
group  communication  layer  provides  the  Virtual  Syn- 


Case  Event  is 
Data_Message : 

deliver (data_msg) 

User_Message : 

broadcast (data_msg) 

Flush_Request : 

Wait_for_sec_f lush_ok  :=  TRUE 
deliver (f lush_request_msg) 

Secure_Flush__Ok : 

if  (Wait_for_sec_f lush_ok) 

Wait_for_sec_f lush_ok  :=  FALSE 
send_f  lush_ok  (Group_name) 
state  :=  WAIT_FOR_CASCADING_MEMBERSHIP 
/*  for  opt.  Alg.,  replace  above  line  with: 
State  :=  WAI T_FOR_MEMBERSHIP  */ 

else 

illegal,  return  an  error  to  the  user 

endif 

Trans it ional_Signal : 

3 

►  deliver (trans_signal_msg) 

First_transitional  :=  FALSE 
VS_transitional  :=  TRUE 

All  other  events : 

not  possible _ 

Figure  4.  Code  executed  in  SECURE  state 


case  Event  is 

Final_Token : 

f a ct_out_ms g  : =  c 1 q_f act o r_out ( C 1 q_ 

final. 

new_gc  :=  clq_new_gc (Clq_cxt ) 
unicast (FIFO, fact_out_msg,  new_gc) 
KL_got_f lush_req  :=  FALSE 
state  :=  WAIT_FOR_KEY_LIST 

_ctx, 

_token_msg) 

Flush_Request : 

send_f  lush_ok  ( Group_name ) 

state  :=  WAIT_FOR_CASCADING_MEMBERSHIP 

Trans it ional_Signal : 

3  if (First_transitional) 

*  deliver (trans_signal_msg) 
First_transitional  :=  FALSE 

endif 

VS_transitional  :=  TRUE 

User_Mes  sage ,  Secure_Flush_Ok : 

illegal,  return  an  error  to  the  user 

All  other  events : 

not  possible 

Figure  5.  Code  executed  in 
WAIT.FOR.FINAL.TOKEN  state 
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Join  group 


□ 


Notes:  VS_set  is  delivered  as  part  of  the  membership 

:  All  Cliques  messages  but  key_list_msg  are  sent  FIFO 
:  A  process  can  leave  the  group  in  any  state 

Figure  2.  Basic  algorithm 


chi'ony  Model.  The  Cliques  protocol  was  proven  to 
be  correct  in  [16].  We  also  note  that,  as  evident  from 
the  state  machine  in  Figure  2,  the  Cliques  GDH  pro¬ 
tocol  remains  intact,  i.e.,  all  of  its  protocol  messages 
are  sent  and  delivered  in  the  same  order  as  specified 
in  [15].  Therefore,  the  basic  robust  key  agreement  al¬ 
gorithm  provides  the  same  security  guarantees  as  the 
Cliques  GDH  protocol. 

A  secure  membership  notification  is  defined  as  a 
notification  delivered  by  the  key-agreement  algorithm, 
and  a  VS  membership  notification  is  a  notification 
delivered  by  the  group  communication  system  to  the 
key-agreement  algorithm.  A  secure  view  is  a  view  in¬ 
stalled  by  the  key-agreement  algorithm  and  a  VS  view 
is  a  view  installed  by  the  group  communication  sys¬ 
tem. 

The  following  two  lemmas  are  straightforward,  but 
they  are  defined  to  clarify  the  proof.  The  first  lemma 


is  part  of  the  VS  Model  provided  by  the  group  com¬ 
munication  system.  The  second  lemma  is  enforced  by 
the  key-agreement  algorithm. 

Lemma  4.1  Every  VS  Membership  event  is  preceded 
by  the  process  sending  a  flusli_okjnsg,  with  the  excep¬ 
tion  of  the  case  when  a  process  joins  a  group.  For  a 
joining  process,  no  flus/i_okjnsg  message  is  sent  and 
the  membership  notification  is  the  first  message  deliv¬ 
ered  to  it. 

Lemma  4.2  A  process  is  not  allowed  to  send  mes¬ 
sages  while  it  is  performing  the  key  agreement  (this 
is  between  the  time  it  sends  a  flush  ok  message  until 
the  time  it  receives  a  secure  membership  notification). 

Some  useful  observations  can  be  made  about  member¬ 
ship  notifications  and  application  messages.  The  key- 
agreement  algorithm  discards  VS  membership  events. 
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case  Event  is 
Partial_Token : 

if ( ! last (Clq_ctx,  Me) ) 

partial_token_msg  :=  clq_update_key (Clq_ctx) 
next_member  :=  clq_next_mernber  (Clq_ctx) 
unicast (FIFO, partial_token_msg, next_member) 
state  :=  WAIT_FOR_FINAL_TOKEN 
else 

f inal_token_msg  :=  partial_token_msg 
broadcast (FIFO,  f inal_token_msg, Group_name) 
state  :=  COLLECT_FACT_OUTS 
endif 

Flush_Request : 

send_f  lush_ok  (Group_name) 

state  :=  WAI  T_FOR_CASCAD  ING_MEMBERSHIP 

Transitional_Signal : 

^  if (First_transitional) 

— ►  deliver  (trans_signal_msg) 

First_transitional  :=  FALSE 

endif 

VS_transitional  :=  TRUE 

User_Mes  sage ,  Secure_Flush_Ok : 

illegal,  return  an  error  to  the  user 

All  other  events : 

not  possible 

Figure  6.  Code  executed  in 
WAIT_FOR_PARTIAL_TOKEN  state 

not  every  VS  view  delivery  event  has  a  corresponding 
secure  view  delivery  event.  The  secure  membership 
notification  is  built  and  saved  in  the  CM  state  (see  Fig¬ 
ure  9).  For  every  VS  membership  received  in  the  CM 
state,  the  list  of  members,  the  view  identifier  and  the 
transitional  set  of  the  new  secure  membership  arc  up¬ 
dated  in  the  New  .membership  variable.  The  only  state 
in  which  a  membership  from  the  group  communica¬ 
tion  system  is  received,  is  CM. 

User  messages  arc  delivered  immediately  as  they 
arc  received,  they  arc  not  delayed  or  reordered.  The 
only  states  which  deliver  user  messages  arc  S  and  CM. 
We  now  prove  the  following  lemmas. 

Lemma  4.3  The  only  state  where  VS  membership  no¬ 
tifications  are  received  by  the  key-agreement  algo¬ 
rithm  is  CM. 


case  Event  is 
Key__List : 

if ( ! VS_transitional) 

Clq_ctx  :=  clq_update_ctx (Clq_ctx, 

key_l  i  s  t_ms  g ) 

Group_Key  :=  clq_get_secret (Clq_ctx) 
New_memb_msg .  vs_set  :=  Vs_set 
deliver (New_memb_msg) 

First_transitional  :=  TRUE 
First_cascaded_membership  :=  TRUE 
State  : =  SECURE 
if  (KL_got_f  lush_req) 

Wait_for_sec_flush_ok  :=  TRUE 
deliver (f lush_request_msg) 
endif 

endif 

Flush_Request : 

if (VS_transitional) 

send_f  lush_ok  (Group_name) 

state  : =  WAIT_FOR_CASCADING_MEMBERSHIP 

endif 

KL_got_f lush_req  :=  TRUE 

Trans it ional_Signal : 

2  if (First_transitional) 

— ►  deliver (trans_signal_msg) 

First_transitional  :=  FALSE 

endif 

if  (KL_got_f  lush_req) 

send_f  lush_ok  (Group_name) 

state  :=  WAIT_FOR_CASCADING_MEMBERSHIP 

endif 

VS_transitional  :=  TRUE 

Userjfes sage ,  Secure_Flush_Ok : 

illegal,  return  an  error  to  the  user 

All  other  events : 

not  possible 

Figure  7.  Code  executed  in 
WAIT_FOR_KEY_LIST  state 


Proof:  By  Lemma  4.1,  a  membership  notifica¬ 
tion  delivery  is  preceded  by  the  process  sending  a 
flush_ok_msg  message,  unless  the  process  is  join¬ 
ing.  By  the  algorithm,  immediately  after  sending  a 
flush_ok_msg  message,  the  process  transitions  to  the 
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case  Event  is 
Fact_out : 

key_list_msg  :=  clq_merge (Clq_ctx, 

fact_out_msg,  key_list_msg) 
if (ready (key_list_msg) ) 

broadcast (SAFE,  key_list_msg,  Group_name) 
KL_got_f lush_req  :=  FALSE 
state  :=  WAI  T_FOR__KE  Y_L  1ST 
endif 

Flush_Request : 

send_f  lush_ok  (Group_name) 

state  :=  WAIT_FOR_CASCADING_MEMBERSHIP 

Trans it ional_Signal : 

3  if (First_transitional) 

— *•  deliver  (trans_signal_msg) 

First_transitional  :=  FALSE 

endif 

VS_transitional  :=  TRUE 

User_Mes  sage ,  Secure_Flush_Ok : 

illegal,  return  an  error  to  the  user 

All  other  events : 

_ not  possible _ 

Figure  8.  Code  executed  in  COL- 
LECT.FACT.OUTS  state 

CM  state  and  does  not  leave  the  CM  state  until  it  re¬ 
ceives  a  Membership  event.  A  joining  process  starts 
executing  the  algorithm  in  the  CM  state  and  does  not 
leave  it  until  it  receives  a  membership  event. 

Lemma  4.4  The  only  states  where  user  messages  are 
received  by  the  key-agreement  algorithm  from  the 
group  communication  system  are  S  and  CM. 

Proof:  After  receiving  a  VS  membership  notification 
in  the  CM  state  (by  Lemma  4.3  this  is  the  only  state 
where  membership  notifications  arc  received)  the  pro¬ 
cess  moves  to  one  of  the  states  FT,  PT,  FO,  KL,  or  S. 
The  transition  to  state  S  installs  a  new  secure  view,  so 
in  that  state  the  process  can  send  and  receive  user  mes¬ 
sages.  In  any  of  the  FT,  PT,  FO,  KL  or  CM  states  the 
process  is  not  allowed  to  send  application  messages. 
If  an  application  message  is  received  in  any  of  the  FT, 
PT,  FO  or  KL  states,  two  cases  arc  possible:  first,  this 
is  a  message  sent  in  the  previous  secure  view  in  state 
S,  or  second,  this  is  a  message  sent  by  a  process  that 
completed  the  key  agreement  before  this  process  did 
and  already  installed  the  new  view  and  sent  messages. 

The  first  case  is  not  possible  because  it  implies 
that  the  group  communication  system  delivered  a  user 


Case  Event  is 
Data_Message : 

deliver (data_msg) 

Trans it ional_Signal : 

^  if (First_transitional) 

— ►  deliver (trans_signal_msg) 

First_transitional  :=  FALSE 

endif 

VS_transitional  :=  TRUE 

Membership : 

^  if (First_cascaded_membership) 

— — ►  VS_set  :=  New_memb_msg .  mb_set 

First_cascaded_membership  :=  FALSE 

^  endif 

— ►  VS_set  :=  VS_set  -  memb_msg.  leave_set 

if ( ! empty (memb_msg . leave_set )  &  & 

^  First_transitional) 

— — ►  deliver (trans_signal_msg) 

First_transitional  :=  FALSE 
2  endif 

—  New_memb_msg . mb_id  :=  memb_msg.mb_id 
-=-►  New_memb_ms  g .  mb_s  e t  :  =  memb_ms  g .  mb_s  et 

if ( ! alone (memb_msg.mb_set) ) 

if  (choose  (memb_msg.mb_set )  ==  Me) 
clq_destroy_ctx (Clq_ctx) 

Clq_ctx  :=  clq_f irst_member (Me, 

Group_name ) 

merge_set  :=  memb_msg.mb_set  —  Me 
partial_token_msg  :=  clq_update_key ( 

Clq_ctx,  merge_set) 

next_membe r  : =  c 1 q_next_member ( C 1 q_ct x ) 
unicast (FIFO,  partial_token_msg, 

next_member ) 

state  :=  WAI T_FOR_F INAL_TOKEN 
else  /*  not  chosen  */ 

clq_destroy_ctx (Clq_ctx) 

Clq_ctx  :=  c 1 q_ne w_membe r ( Me ) 
state  :=  WAI  T_FOR_P  ART  I  AL_TOKEN 
endif 

else  /*  alone  */ 

clq_destroy_ctx (Clq_ctx) 

Clq_ctx  :=  clq_f irst_member (Me, Group_name) 
Group_key  :=  clq_extract_key (Clq_ctx) 
New_mernb_msg .  vs_set  :=  Me 
deliver (New_memb_msg) 

First_transitional  :=  TRUE 
First_cascaded_membership  :=  TRUE 
State  :=  SECURE 

endif 

VS_transitional  :=  FALSE 

Partial_Token,  Final_Token,  Fact_out,  Key_List : 

ignore 

User_Mes  sage ,  Secure_Flush_Ok : 

illegal,  return  an  error  to  the  user 

All  other  events : 

not  possible 

Figure  9.  Code  executed  in 

WAIT.FOR.CASCADING.MEMBERSHIP 

state 
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message  not  in  the  view  in  which  it  was  sent,  which 
contradicts  the  Sending  View  Delivery  property.  In  the 
second  case,  note  that  the  key  list  message  is  broadcast 
as  a  safe  message.  A  user  message  can  not  be  received 
in  the  KL  state  before  the  key  list  message  because  it 
was  sent  after  its  sender  processed  the  key  list  mes¬ 
sage.  This  contradicts  the  Causal  Delivery  property. 
Therefore  the  only  states  where  a  process  can  receive 
user  messages  arc  S  and  CM. 

4.2.1  Self  Inclusion 

Theorem  4.1  When  process  p  installs  a  secure  view, 
the  view  includes  p. 

Proof:  By  the  protocol,  we  update  the  view- 

to-be-installed  only  when  a  membership  notifica¬ 
tion  is  received  from  GCS  (i.e.,  when  we  update 
New  Membership. mb  set  in  Figure  9,  M  ark  2).  By 
Lemma  4.3,  this  occurs  only  in  the  CM  state. 

By  the  algorithm,  there  arc  two  transitions  that  in¬ 
stall  secure  views.  The  first  transition  corresponds  to 
a  Membership  event  occurrence  in  the  CM  state,  in¬ 
dicating  that  process  p  is  alone.  In  this  case,  the  se¬ 
cure  membership  notification  is  immediately  delivered 
withp  (the  only  one)  in  it.  The  second  transition  corre¬ 
sponds  to  a  Key_List  event  occurrence  in  the  KL  state. 
In  this  case,  at  the  time  the  new  secure  view  is  deliv¬ 
ered,  it  indicates  the  VS  group  members  list,  and  as 
GCS  provides  Self  Inclusion,  p  is  guaranteed  to  be  on 
that  list. 

4.2.2  Local  Monotonicity 

Lemma  4.5  The  identifier  of  a  secure  view  is  the  iden¬ 
tifier  of  the  most  recently  installed  VS  view. 

Proof:  By  the  protocol,  we  update  the  view- 

to-be-installed  only  when  a  membership  notifica¬ 
tion  is  received  from  GCS  (i.e.,  when  we  update 
NewM.embership.mbJd  in  Figure  9,  Mark  1).  By 
Lemma  4.3,  this  occurs  only  in  the  CM  state. 

By  the  algorithm,  there  arc  two  transitions  that  in¬ 
stall  secure  views.  The  first  transition  corresponds  to  a 
Membership  event  received  in  the  CM  state,  indicating 
that  process  p  is  alone.  In  this  case,  the  secure  mem¬ 
bership  notification  is  immediately  delivered  with  the 


most  recent  VS  identifier.  The  second  transition  cor¬ 
responds  to  a  Key_List  event  received  in  the  KL  state. 
In  this  case,  when  the  secure  view  is  delivered,  it  indi¬ 
cates  the  most  recent  VS  identifier. 

Theorem  4.2  If  process  p  installs  a  secure  view  vsec 
after  installing  a  view  vsec'  then  the  identifier  of 
vsec  is  greater  than  the  identifier  of  v sec' . 

Proof:  The  algorithm  does  not  create  or  change  view 
identifiers.  It  only  uses  the  identifiers  provided  by 
the  VS  membership  notifications  without  reordering 
them.  By  Lemma  4.5,  p  always  delivers  a  secure 
view  with  the  same  identifier  as  the  most  recent  VS 
identifier,  therefore,  it  delivers  a  subsequence  of  the 
sequence  of  VS  identifiers.  Because  it  delivers  a 
subsequence  of  VS  identifiers  and  because  GCS  pro¬ 
vides  Local  Monotonicity,  the  key-agreement  algo¬ 
rithm  provides  Local  Monotonicity  too. 

4.2.3  Sending  View  Delivery 

Theorem  4.3  A  message  is  delivered  by  the  key- 
agreement  algorithm  in  the  secure  view  that  it  was  sent 
in. 

Proof:  By  the  algorithm,  messages  arc  delivered 
by  the  key-agreement  algorithm  only  in  the  S  and 
CM  states.  In  the  S  state,  the  secure  view  is 
the  most  recent  VS  view  (i.e.,  when  we  update 
New  Membership. mbset  in  Figure  9,  Mark  2).  By  the 
Sending  View  Delivery  property  of  GCS,  the  above 
claim  is  true. 

By  the  algorithm,  a  process  moves  to  the  CM  state 
after  the  application  agreed  to  close  the  membership 
by  sending  a  flush_ok  message  (see  Figure  4).  Since 
the  key-agreement  algorithm  delivers  a  message  im¬ 
mediately  after  it  was  received  and  GCS  provides 
Sending  View  Delivery,  all  the  messages  sent  in  view 
v  will  be  delivered  before  the  next  VS  view  was  re¬ 
ceived,  and  therefore,  before  a  new  secure  view  is  in¬ 
stalled. 

4.2.4  Delivery  Integrity 

Theorem  4.4  If  process  p  delivers  a  message  m  in  a 
secure  view  v,  then  there  exists  a  process  q  that  sent 
m  in  v  causally  before  p  delivered  m. 
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Proof:  This  proof  contains  two  parts.  First,  we  show 
that  the  key-agreement  algorithm  delivers  message  m 
causally  after  it  was  sent.  This  is  true  by  transitivity 
since: 

•  The  key-agreement  algorithm  sends  m  immedi¬ 
ately  after  it  was  sent  by  the  application. 

•  By  the  delivery  integrity  property  of  GCS,  the 
group  communication  system  delivers  message 
m  causally  after  it  was  sent. 

•  The  key-agreement  algorithm  delivers  m  imme¬ 
diately  after  it  was  received  from  the  group  com¬ 
munication  system. 

Note  that  the  user  messages  arc  not  reordered,  they  arc 
delivered  as  soon  as  they  are  received. 

Second,  we  show  that  if  process  p  delivers  message 
m  in  v,  then  there  exists  a  process  q  that  sent  m  in  v. 
This  claim  is  true  by  Theorem  4.3. 

4.2.5  No  Duplication 

Theorem  4.5  A  message  is  not  sent  twice  using  the 
key-agreement  algorithm.  The  key-agreement  algo¬ 
rithm  does  not  deliver  a  message  twice  to  the  same 
process. 

Proof:  By  the  algorithm,  user  messages  are  sent  only 
in  the  S  state,  when  the  application  is  sending  them, 
so  a  message  is  not  sent  twice. 

By  the  algorithm,  messages  arc  delivered  only  in 
the  S  and  CM  states.  They  arc  delivered  immediately 
upon  receipt  from  the  group  communication  system. 
Since  GCS  guarantees  no  duplication,  it  can  not  be 
that  a  message  sent  once  to  the  group  communication 
system  is  received  twice.  Note  that  the  key-agreement 
algorithm  generates  Cliques  messages,  but  these  arc 
never  delivered  to  the  application  so  they  do  not  affect 
the  No  Duplication  property. 

4.2.6  Self  Delivery 

Theorem  4.6  If  process  p  sends  a  message  m ,  then  p 
delivers  m  unless  it  crashes. 

Proof:  By  the  algorithm,  a  message  is  sent  by  the 
application  via  the  group  communication  system  and 


the  key-agreement  algorithm  never  discards  applica¬ 
tion  messages  and  it  delivers  them  immediately  after 
receiving  them.  Since  GCS  provides  Self  Delivery,  the 
theorem  is  true. 

4.2.7  Transitional  Set 

Lemma  4.6  If  process  p  installed  a  secure  view  vsec 
with  process  q  in  the  members  set,  they  both  install  the 
same  next  VS  view,  and  p ’s  VS  transitional  set  includes 
q,  then  q  must  have  installed  vsec. 

Proof:  By  the  protocol,  a  process  installs  a  secure 
view  with  more  than  one  member  only  in  the  KL 
state.  A  process  in  the  KL  state  installs  a  secure  view 
if  and  only  if  it  receives  a  key _list_msg  message  be¬ 
fore  a  transitional  signal  for  the  current  VS  view.  Be¬ 
cause  p  and  q  move  together  to  the  new  VS  view 
and  the  key_list_msg  is  a  safe  message,  by  the  Safe 
Delivery  properties  of  GCS,  q  must  also  receive  the 
key_list_msg  message  before  the  transitional  signal. 
Therefore,  q  must  also  have  installed  vsec. 

Theorem  4.7  If  two  processes  p  and  q  install  the 
same  secure  view  vsec,  and  q  is  included  dip’s  tran¬ 
sitional  set  for  this  view,  then  p ’s  previous  secure  view 
was  identical  to  q ’s  previous  secure  view. 

Proof:  By  the  algorithm,  the  transitional  set  for  a  new 
secure  membership  notification  is  initialized  to  be  the 
same  as  the  previous  secure  view  member  set.  Further¬ 
more,  we  only  remove  from  this  set  members  reported 
by  VS  membership  notifications  as  not  being  in  our 
VS  transitional  set  (i.e.  the  leaveset),  and  we  never 
add  members  to  the  transitional  set.  Due  to  this,  if  q  is 
included  in  p’s  secure  transitional  set  then  q  must  have 
been  included  in  all  of  p’s  VS  transitional  sets  since 
the  last  secure  view  delivered  at  p.  Additionally,  p  and 
q  must  have  installed  the  same  sequence  of  VS  views 
prior  to  vsec  because  they  both  installed  the  VS  view 
corresponding  to  vsec  and  because  of  the  GCS  tran¬ 
sitional  set  property  number  two. 

Therefore,  by  Lemma  4.6,  q  must  have  installed  the 
same  previous  secure  view  as  p.  To  show  that  q  in¬ 
stalled  no  intervening  secure  views,  the  same  proof  is 
repeated  reversing  p  and  q’s  roles  with  the  additional 
information  that  p  is  in  q’s  secure  transitional  set  be¬ 
cause  of  the  way  the  set  is  computed  and  GCS  transi¬ 
tional  set  property  number  two. 
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Theorem  4.8  If  two  processes  p  and  q  install  the 
same  secure  view,  and  q  is  included  in  p  ’s  transitional 
set  for  this  view,  then  p  is  included  in  q’s  transitional 
set  for  this  view. 

Proof:  If  p  and  q  install  the  same  secure  view,  and 
q  is  included  in  p's  transitional  set  for  this  view,  but 
p  is  not  included  in  q's  transitional  set  for  this  view, 
two  cases  arc  possible.  First,  q's  previous  secure  view 
was  not  the  same  as  p's  secure  view.  In  this  case,  by 
theorem  4.7,  q  is  not  included  in  p's  transitional  set, 
contradicting  our  assumption  that  q  is  included  in  p’s 
transitional  set. 

Second,  q's  previous  secure  view  was  the  same,  but 
an  intermediary  VS  notification  delivered  to  q  did  not 
include  p  in  its  transitional  set.  Since  p  and  q  install 
the  same  secure  view,  it  must  be  that,  p  and  q  install 
the  same  VS  view  at  some  point.  The  first  such  view 
installed  at  q  preserves  that  p  is  not  in  q's  transitional 
set  by  GCS  transitional  set  property  number  one.  By 
GCS  transitional  set  property  number  two,  p  must  not 
have  q  in  its  transitional  set  for  that  view.  By  the  proto¬ 
col,  then  q  is  removed  from  p’s  secure  transitional  set, 
and  because  p’s  transitional  set  never  grows  q  will  not 
be  in  p’s  secure  transitional  set  when  p  and  q  install  the 
new  secure  view,  which  contradicts  our  assumption. 

4.2.8  Virtual  Synchrony 

Theorem  4.9  Two  processes  p  and  q  that  move  to¬ 
gether  through  two  consecutive  secure  views,  deliver 
the  same  set  of  messages  in  the  former  view. 

Proof:  By  Lemma  4.4,  user  messages  arc  received 
by  the  key-agreement  algorithm  only  in  the  S  or  CM 
states  and  as  specified  by  the  protocol,  they  are  de¬ 
livered  as  soon  as  they  are  received.  Therefore,  user 
messages  arc  delivered  only  in  the  S  and  CM  states. 

By  Lemma  4.3,  VS  membership  notifications  arc 
received  only  in  the  CM  state.  By  the  protocol  (the 
way  we  compute  the  transitional  set),  if  process  p  and 
q  move  together  from  vl sec  to  v2_sec,  then  p  and  q 
moved  together  through  the  sequence  of  VS  views  vl 
to  nli,  ...,  nln_i  to  vln,  vln  to  v2  5. 

Therefore,  by  the  Virtual  Synchrony  property  guar¬ 
anteed  by  GCS,  processes  p  and  q  deliver  the  same 

’Note  that  n  can  be  zero  with  the  in-between  set  potentially 
empty  (vl  to  v2). 


set  of  messages  between  vl  and  vl\,  vl\  and  vl-2,  ... 
vln  and  v2.  No  other  messages  are  delivered  between 
v2  and  v2 _sec  installations  because  any  such  message 
has  to  be  sent  in  v2  by  the  GCS  Sending  View  De¬ 
livery  property.  By  the  protocol,  upon  sending  the 
flush_ok_msg  message  that  concludes  v  1  each  process 
moves  to  the  CM  state  and  by  Lemma  4.2,  will  not 
send  data  messages  before  installing  v2_sec.  In  partic¬ 
ular,  it  will  not  send  messages  between  v2  and  v2sec. 
Therefore,  p  and  q  deliver  the  same  set  of  messages  in 
vlsec. 

4.2.9  Causal  Delivery 

Lemma  4.7  All  the  messages  delivered  by  the  key- 
agreement  algorithm,  support  the  ordering  properties 
with  which  they  were  delivered  by  the  group  commu¬ 
nication  system. 

Proof:  By  the  protocol,  the  messages  delivered  by  a 
process  in  secure  view  vsec,  are  messages  delivered 
by  the  GCS  in  VS  view  v.  Since  messages  are  de¬ 
livered  to  the  application  in  the  order  they  were  re¬ 
ceived  from  the  GCS,  without  being  delayed,  no  ap¬ 
plication  messages  arc  dropped  or  duplicated,  and  no 
phantom  messages  arc  generated,  the  messages  deliv¬ 
ered  in  vsec,  support  the  same  ordering  requirements 
as  they  were  delivered  in  v. 

Theorem  4.10  If  message  m  causally  precedes  mes¬ 
sage  m1,  and  both  are  sent  in  the  same  secure  view, 
then  any  process  q  that  delivers  m!  delivers  m  before 
m1. 

Proof:  This  is  true  by  Lemma  4.7. 

4.2.10  Agreed  Delivery 

Theorem  4.11  If  messages  m  and  m!  are  delivered  at 
process  p  in  this  order,  and  m  and  m!  are  delivered  by 
process  q  then  m!  is  delivered  by  q  after  m  is  delivered 
by  q. 

If  messages  m  and  m!  are  delivered  by  process  p  in 
secure  view  vl  sec  in  this  order,  and  m!  is  delivered 
by  process  q  in  secure  view  v2_sec  and  message  m 
was  sent  by  a  process  r  which  is  a  member  of  secure 
view  v2_sec,  then  q  delivered  m. 
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Proof:  This  is  true  by  Lemma  4.7  and  because  the  se¬ 
cure  transitional  set  is  the  intersection  of  all  the  VS 
transitional  sets. 

4.2.11  Safe  Delivery 

Theorem  4.12  If  process  p  delivers  a  safe  message  m 
in  view  v  before  the  transitional  signal,  then  every  pro¬ 
cess  q  of  view  v  delivers  m  unless  it  crashes.  If  process 
p  delivers  a  safe  message  m  in  view  v  after  the  transi¬ 
tional  signal,  then  every  process  q  that  belongs  to  p  ’s 
transitional  set  delivers  m  after  the  transitional  signal 
unless  it  crashes. 

Proof:  By  Lemma  4.7,  key-agreement  delivers  mes¬ 
sages  with  the  same  ordering  guarantees  with  which 
they  were  delivered  by  the  GCS. 

By  the  algorithm,  the  first  transitional  signal  re¬ 
ceived  from  GCS  is  delivered  to  the  application  (see 
Mark  3  in  Figures  4,  7,  6,  5,  8,  9). 

By  the  algorithm,  the  transitional  set  delivered  with 
a  new  secure  membership  in  calculated  as  follows, 
when  a  group  change  happens  while  the  group  is  stable 
(state  S),  the  transitional  set  is  initialized  to  the  current 
secure  membership  list  (see  Mark  4,  in  Figure  9)  and 
then  every  time  another  membership  happens  before 
installing  this  secure  membership,  the  members  that 
left  the  group  are  removed  from  the  transitional  set, 
such  that  when  the  new  secure  membership  is  deliv¬ 
ered,  the  transitional  set  is  correct.  Therefore,  the  safe 
delivery  requirements  are  preserved. 

5  An  Optimized  Robust  Algorithm 

In  this  section  we  show  how  the  algorithm  pre¬ 
sented  in  the  previous  section  can  be  optimized, 
such  that  the  price  paid  for  handling  common,  non- 
cascaded  events  is  lower,  while  preserving  the  same 
set  of  group  communication  semantics  and  security 
guarantees. 

5.1  Algorithm  Description 

The  basic  algorithm  presented  in  Section  4  is  ro¬ 
bust  even  when  cascaded  group  events  occur.  Every 
time  a  membership  notification  is  delivered  from  the 
group  communication  system,  the  algorithm  ignores 


all  the  previous  key  agreement  information  and  starts 
the  merge  protocol  choosing  a  member  from  the  new 
group  to  initialize  it.  Therefore,  this  algorithm  pays 
more  than  necessary  for  computing  a  group  key  in  a 
regular  case,  because  it  does  not  distinguish  between 
a  membership  that  finished  without  being  interrupted 
and  a  cascaded  membership. 

The  algorithm  described  above  can  be  optimized  so 
that  it  distinguishes  between  these  two  cases.  Every 
time  the  group  view  changes,  the  algorithm  detects 
the  cause  of  the  group  change  (join,  leave,  partition, 
merge  or  a  combination  of  partition  and  merge)  and 
invokes  the  Cliques  GDH  specific  protocol.  For  ex¬ 
ample,  in  the  case  where  a  leave  occurred,  the  leave 
protocol  is  invoked.  Computing  a  new  key  in  the  case 
that  a  leave  or  partition  occurred,  requires  only  one 
broadcast.  Thus,  leave  events  can  be  handled  imme¬ 
diately  with  a  lower  communication  and  computation 
cost  than  the  basic  algorithm  required. 

In  the  optimized  key-agreement  algorithm  the  pro¬ 
cess  still  starts  executing  the  state  machine  by  invok¬ 
ing  the  Join  primitive.  Also,  at  any  moment,  a  pro¬ 
cess  can  voluntarily  leave  the  algorithm  by  invoking 
the  Leave  primitive. 

The  optimized  algorithm  utilizes  the  following  two 
states  in  addition  to  those  of  the  basic  algorithm: 

•  WAIT  _FOR_S  ELF  JOIN  (SJ):  this  is  the  initial 
state  in  which  a  process  that  joined  a  group  en¬ 
ters  the  state  machine;  the  process  is  waiting  for 
the  membership  message  that  notifies  the  group 
about  its  joining.  In  case  a  network  event  happens 
between  the  join  request  and  the  membership  no¬ 
tification  delivery,  the  GCS  will  report  the  cause 
of  the  group  change  as  being  a  network  event  and 
the  transitional  set  will  contain  only  the  joining 
member.  The  only  possible  event  is  a  Member¬ 
ship.  User_Message  and  Secure_Flush_Ok  events 
arc  illegal.  An  error  will  be  returned  to  the  user  if 
they  are  attempted.  All  other  events  arc  not  pos¬ 
sible. 

•  WAIT _FOR_MEMBERSHIP  (M):  in  this  state 
the  process  is  waiting  for  a  membership  no¬ 
tification.  The  possible  events  arc:  Transi- 
tionaLSignal,  Data_Message  and  Membership. 
The  membership  notification  can  be  caused 
by  voluntarily  events  such  as  join  or  leave, 
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or  network  events.  User_Message  and  Se- 
cure_Flush_Ok  events  arc  illegal.  An  error  will 
be  returned  to  the  user.  All  other  events  are  not 
possible. 

While  a  process  stalls  the  basic  algorithm  in  the  CM 
state,  in  the  optimized  algorithm  a  process  stalls  the 
algorithm  in  state  SJ.  From  the  stable  state  (S  state)  if 
the  group  changed  the  process  moves  to  the  M  state 
instead  of  moving  to  the  CM  state  as  in  the  basic  algo¬ 
rithm.  From  here,  depending  on  the  cause  of  the  group 
change,  the  merge  or  the  leave  Cliques  GDH  protocols 
arc  invoked.  Also,  a  combined  network  event  which 
includes  both  joins  and  leaves  simultaneously  can  be 
handled  by  a  modified  version  of  the  Cliques  GDF1 
merge  protocol  (as  described  in  Section  5.2).  If  an¬ 
other  group  change  happens  before  a  key  is  computed, 
the  process  will  move  to  the  CM  state  and  execute  the 
basic  algorithm. 

The  merge jset  and  leaveset  fields  of  the  member¬ 
ship  notification  can  be  used  to  determine  the  cause  of 
the  group  view  change.  In  addition,  we  use  a  mod¬ 
ified  version  of  the  procedure  clq_update_key  proce¬ 
dure  which  can  handle  combined  network  events. 

The  diagram  of  the  state  machine  of  the  algorithm  is 
presented  in  Figure  12  and  the  corresponding  pseudo¬ 
code  in  Figures  4,5,  6,  7,  8,  9,  10,  11. 

5.2  Handling  Bundled  Events 

Most  group  events  arc  homogeneous  in  nature: 
leave  (partition)  or  join  (merge)  of  one  or  more  mem¬ 
bers.  However,  a  group  communication  system  can 
decide  to  bundle  several  such  events  if  they  occur  in 
close  proximity,  i.e.,  within  a  very  short  time  interval. 
The  main  incentive  for  doing  so  is  to  reduce  commu¬ 
nication  costs  and  limit  the  impact  and  overhead  on 
the  application. 

As  mentioned  above.  Cliques  provides  two  separate 
protocols  that  handle  leave  and  merge  events.  Each  of 
these  protocols  can  trivially  handle  bundled  events  of 
the  same  type,  i.e.,  the  Cliques  merge  protocol  can  ac¬ 
commodate  any  combination  of  bundled  merges  and 
the  Cliques  leave  protocol  can  do  the  same  for  any 
combination  of  leaves  and  partitions.  A  more  interest¬ 
ing  scenario  occurs  when  a  single  membership  event 
bundles  merges/joins  with  leaves/partitions.  One  ob¬ 
vious  way  to  handle  this  type  of  event  is  to  first  in- 


Case  Event  is 

Membership : 

4 

^  *  V S_s  e t  :  =  Ne w_memb_ms  g .  mb_s  e t 

*  Ne w_memb_ms  g .  mb_i  d  :  =  memb_ms  g .  mb_i  d 

— ►New_memb_msg.mb_set  :=  memb_msg.mb_set 
First_cascaded_membership  :=  FALSE 
if ( ! alone (memb_msg.mb_set) ) 

if (choose (memb_msg .mb_set)  =  Me) 

Clq_ctx  :=  clq_f irst_member (Me, 

Group_name ) 

merge_set  :=  memb_msg.merge_set 
partial_token_msg  :=  clq_update_key ( 

Clq_ctx,  merge_set ) 

next_membe r  : =  c 1 q_next_membe r ( C 1 q_ct x ) 
unicast (FIFO, partial_token_msg, 

next_member ) 

state  :=  WAI  T_FOR_F  INAL__TOKEN 
else 

Clq_ctx  :=  clq_new_member (Me) 
state  :=  WAI  T_FOR_P  ART  I  AL_TOKEN 
endif 
else 

Clq_ctx  :=  clq_f irst_member  (Me,  Group_name) 
Group_key  :=  clq_extract_key (Clq_ctx) 
New_memb_msg. vs_set  :=  Me 
deliver (New_memb_msg) 
First_cascaded_membership  :=  TRUE 
State  :=  SECURE 
endif 

VS_transitional  :=  FALSE 

User_Mes  sage ,  Secure_Flush_Ok : 

illegal,  return  an  error  to  the  user 

All  other  events : 

not  possible 

Figure  10.  Code  executed  in 
WAIT_FOR_SELF_JOIN  state 
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|  1  |  Join  group 


NET  &  I’m  not  alone  & 
is_Merge  &  I  am  a  new  guy: 
update  VS  set 


MEMB  &  I’m  alone: 
update  key, 

□  update  VS  set 
install  memb. 


Notes:  VS_set  is  delivered  as  part  of  the  membership 

:  All  Cliques  messages  but  key_list_msg  are  sent  FIFO;  key_list_msg  is  sent  as  a  safe  message. 
:  A  process  can  leave  the  group  in  any  state 


Figure  12.  Optimized  algorithm 


voke  Cliques  leave  to  process  all  leaves/partitions  and 
then  invoke  Cliques  merge  to  process  joins/merges. 
However,  this  is  inefficient  since  the  group  would  es¬ 
sentially  perform  two  separate  key  agreement  proto¬ 
cols  where  only  one  is  truly  needed.  We  can  take 
advantage  of  the  fact  that  both  protocols  in  Cliques 
arc  initiated  by  the  group  controller.  After  processing 
all  leaves/partitions,  the  group  controller  can  suppress 
the  usual  broadcast  of  new  partial  keys  and,  instead, 
forward  the  resulting  set  to  the  first  merging/joining 
member  thereby  initiating  a  merge  protocol.  This 
saves  an  extra  round  of  broadcast  and  at  least  one  cryp¬ 
tographic  operation  for  each  member. 

5.3  Correctness  Proof 

In  this  section  we  prove  that  the  optimized  algo¬ 
rithm  described  above  provides  the  virtual  synchrony 


semantic  presented  in  Section  3.2. 

We  note  that  the  optimized  algorithm  state  machine 
utilizes  two  more  states  that  can  install  secure  mem¬ 
berships:  SJ  and  M.  In  both  of  these  states  a  secure 
view  can  be  installed  only  in  the  special  case  when  the 
group  consists  of  only  one  member  so  the  process  can 
compute  a  key  and  install  the  secure  memberships. 

Unlike  the  basic  algorithm  where  application  mes¬ 
sages  were  delivered  only  in  states  S  and  CM,  in  the 
optimized  algorithm  application  messages  arc  deliv¬ 
ered  in  the  S  and  M  states.  Membership  notifications 
arc  received  in  the  CM,  SJ,  and  M  states. 

It  can  be  noticed  that  for  the  optimized  algorithm,  a 
process  stalls  the  algorithm  in  the  SJ  state.  Also,  from 
the  stable  state  (the  S  state),  due  to  a  group  change 
notification  that  triggers  the  key-agreement  algorithm, 
instead  of  moving  to  the  CM  state  as  in  the  basic  algo¬ 
rithm,  the  process  moves  to  the  M  state.  A  process  can 
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Case  Event  is 


Data_Message : 

deliver (data_msg) 

Transitional_Signal : 

if  (Fi  rst_transitional) 

— — ►  deliver (trans_signal_msg) 

First_transitional  :=  FALSE 

endif 

VS_transitional  :=  TRUE 


Membership : 


4 


VS_set  :  =  New_memb_msg .  mb_set 
VS_set  :=  VS_set  -  memb_msg .  leave_set 
New_memb_msg .  mb_id  :=  memb_msg .  mb_id 
New_memb_ms  g .  mb_set  :  =  memb_ms  g .  mb_s  et 
New_memb_ms  g .  vs_s  e  t  :  =  V  s_s  et 
First_cascaded_membership  :=  FALSE 
if  ( !  alone  (memb_msg.mb_set)  ) 

merge_set  :=  memb_msg .  merge_set 
leave_set  :  =  memb_msg .  leave_set 
if ( ! empty (leave_set)  | |  empty (merge_set) ) 

if (choose (memb_msg.mb_set)  =  Me) 

key_list_msg  :=  clq_leave (Clq_ctx, 

leave_set) 

broadcast (SAFE, key_list_msg, Group_name) 

endif 

State  :=  WAI  T_FOR_KE  Y__L  1ST 
else 

if  (is_  _in  (chosen  (mernb_msg.mb_set)  , 

memb_msg .  vs_set )  )  /*  old  member  */ 
if (choose (memb_msg.mb_set)  =  Me) 

partial_token_msg  :=  clq__update_key  ( 
Clq_ctx,  leave_set ,  merge_set ) 
next_member  :=  clq_next_member ( 

Clq_ctx) 

unicast (FIFO,  partial_token_msg, 

next_member ) 


state  :=  WAIT_FOR_FINAL_TOKEN 
endif 

else  /*  new  member  */ 

clq_destroy_ctx (Clq_ctx) 

Clq_ctx  :=  clq_new_member (Me) 
state  :=  WAIT_FOR_PARTIAL_TOKEN 
endif 

else  /*  alone  */ 

Clq_ctx  :=  clq_first_member (Me,  Group_name) 
Group_key  :=  clq_extract_key (Clq_ctx) 
New_memb_msg. vs_set  :=  Me 
deliver (New_memb_msg) 

First_transitional  :=  TRUE 
First_cascaded_membership  :=  TRUE 
State  :=  SECURE 
endif 

VS_transitional  :=  FALSE 


User_Mes  sage ,  Secure_Flush_Ok : 

illegal,  return  an  error  to  the  user 

All  other  events : 


not  possible 


Figure  11.  Code  executed  in 
WAIT.FOR.MEMBERSHIP  state 


move  in  the  CM  state  only  from  the  PT,  FT,  FO,  and 
KL  states.  From  the  moment  that  the  process  moves 
to  the  CM  state,  it  executes  the  basic  algorithm. 

For  the  rest  of  the  proof,  we  make  use  of  Lem¬ 
mas  4. 1  and  4.2  which  are  still  valid.  The  first  lemma 
is  a  property  of  the  underlying  group  communica¬ 
tion  layer  and  the  second  one  is  enforced  by  the  key- 
agreement  algorithm.  We  also  note  that  Lemma  4.2 
which  specifies  that  a  process  is  not  allowed  to  send 
user  messages  while  performing  the  key-agreement 
algorithm,  enforces  that  a  process  can  not  send  user 
messages  in  any  of  the  M,  CM,  PT,  FT,  FO,  or  KL 
states. 

Lemma  5.1  The  only  states  where  VS  membership 
notifications  are  received  are  the  SJ,  CM  and  M  states. 

Proof:  By  Lemma  4.1,  a  membership  notifica¬ 
tion  delivery  is  preceded  by  the  process  sending  a 
flush_ok_msg  message,  unless  the  process  is  join¬ 
ing.  By  the  algorithm,  immediately  after  sending  a 
flush_ok_msg  message,  the  process  transitions  to  ei¬ 
ther  the  M  or  CM  states  and  does  not  leave  these  states 
until  it  receives  a  Membership  event.  A  joining  pro¬ 
cess  starts  executing  the  algorithm  in  the  SJ  state  and 
does  not  leave  it  until  it  receives  a  membership  event. 

Lemma  5.2  The  only  states  where  user  messages  can 
be  received  are  S  and  M. 

Proof:  By  the  protocol,  in  the  S  state  the  process  can 
send  and/or  receive  messages.  By  Lemma  4.1,  the  first 
message  that  a  process  receives  in  the  SJ  state  is  the 
VS  membership  notification  which  triggers  immedi¬ 
ately  a  transition  to  another  state,  so  no  user  messages 
arc  received  in  the  SJ  state. 

After  receiving  a  VS  membership  notification  from 
GCS  in  any  of  the  SJ,  M  or  CM  states  (by  Lemma  5.1 
these  arc  the  only  states  where  membership  notifica¬ 
tions  arc  received),  the  process  moves  to  one  of  the 
states  FT,  PT,  FO,  KL,  or  S.  The  transition  to  state  S 
installs  a  new  secure  view,  so  in  that  state  the  process 
can  send  and  receive  user  messages.  In  any  of  the  M, 
FT,  PT,  FO,  KL  or  CM  states  the  process  is  not  al¬ 
lowed  to  send  application  messages.  If  an  application 
message  is  received  in  any  of  the  CM,  FT,  PT,  FO  or 
KL  states,  two  cases  are  possible:  first,  this  is  a  mes¬ 
sage  sent  in  the  previous  secure  view  in  state  S,  or  sec¬ 
ond,  this  is  a  message  sent  by  a  process  that  completed 
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the  key-agreement  algorithm  before  this  process  did 
and  already  installed  the  new  view  and  sent  messages. 

The  first  case  is  not  possible  because  it  implies 
that  the  group  communication  system  delivered  a  user 
message  not  in  the  view  in  which  it  was  sent,  which 
contradicts  the  Sending  View  Delivery  property.  In  the 
second  case,  note  that  the  key  list  message  is  broadcast 
as  a  safe  message.  A  user  message  can  not  be  received 
in  the  KL  state  before  the  key  list  message  because  it 
was  sent  after  its  sender  processed  the  key  list  mes¬ 
sage.  This  contradicts  the  Causal  Delivery  property. 
Therefore  the  only  states  where  a  process  can  receive 
user  messages  arc  S  and  M. 

5.3.1  Self  Inclusion 

Theorem  5.1  When  process  p  installs  a  secure  view, 
the  view  includes  p. 

Proof:  By  the  protocol,  we  update  the  view-to-be- 
installed  only  when  a  membership  is  received  from 
GCS  (i.e.,  when  we  update  N ew jnemhership.mh _sel 
in  Figures  9,  11  and  10,  Mark  2).  By  Lemma  5.1, 
this  occurs  only  in  the  SJ,  M  and  CM  states. 

By  the  algorithm,  there  arc  four  transitions  that  in¬ 
stall  secure  views.  The  first  three  transitions  corre¬ 
spond  to  a  Membership  event  received  in  the  CM,  M, 
or  SJ  states,  indicating  that  process  p  is  alone.  In  this 
case,  the  secure  membership  is  immediately  delivered 
with  p  (the  only  one)  in  it. 

The  fourth  transition  corresponds  to  a  KeyXist 
event  received  in  the  KL  state.  In  this  case,  at  the  time 
the  new  secure  view  is  delivered  it  indicates  the  most 
recent  VS  group  members  list,  and  as  the  group  com¬ 
munication  system  provides  Self  Inclusion,  p  is  guar¬ 
anteed  to  be  on  that  list. 

5.3.2  Local  Monotonicity 

The  proof  of  this  property  is  very  similar  to  the  one 
we  gave  for  the  basic  algorithm.  It  is  enough  to  show 
that  Lemma  4.5  is  still  true  for  the  optimized  proto¬ 
col,  therefore,  by  Theorem  4.2,  Local  Monotonicity  is 
provided  by  the  key-agreement  algorithm. 

Lemma  5.3  The  identifier  of  a  secure  view  is  the  iden¬ 
tifier  of  the  most  recently  installed  VS  view. 


Proof:  By  the  protocol,  we  update  the  view-to-be- 
installed  only  when  a  membership  is  received  from 
GCS  (i.e.,  when  we  update  New  jnemhership.mh  Jd  in 
Figures  9,  10,  and  11,  Mark  1).  By  Lemma  5.1,  this 
occurs  only  in  the  CM,  SJ,  and  M  states. 

By  the  algorithm,  there  are  four  transitions  that  in¬ 
stall  secure  views.  The  first  three  transitions  corre¬ 
spond  to  a  Membership  event  received  in  one  of  the 
CM,  SJ,  or  M  states,  indicating  that  process  p  is  alone. 
In  this  case,  the  secure  membership  is  immediately  de¬ 
livered  with  the  most  recent  VS  identifier. 

The  fourth  transition  corresponds  to  a  KeyXist 
event  received  in  the  KL  state.  In  this  case,  when  the 
view  is  delivered,  it  indicates  the  most  recent  VS  iden¬ 
tifier. 

5.3.3  Sending  View  Delivery 

Theorem  5.2  A  message  is  delivered  by  the  key- 
agreement  algorithm  in  the  secure  view  that  is  was 
sent  in. 

Proof:  By  the  algorithm,  messages  arc  delivered  only 
in  the  S  and  M  states.  In  the  S  state,  the  secure  mem¬ 
bership  is  the  most  recent  VS  membership  (i.e.,  when 
we  update  Newjnembership.mbset  in  Figure  9,  mark 
2).  By  the  GCS  Sending  View  Delivery  property,  all 
the  messages  sent  in  the  S  state  arc  delivered  in  the 
secure  view  that  they  were  sent  in. 

By  the  algorithm,  a  process  moves  to  the  M  state  af¬ 
ter  the  application  agreed  to  close  the  membership  by 
sending  a  flush_ok  message  (see  Figure  4).  The  group 
communication  system  guarantees  that  before  deliver¬ 
ing  the  new  VS  view,  it  will  deliver  all  the  messages 
that  were  sent  in  the  previous  view.  Since  the  key- 
agreement  algorithm  delivers  a  message  immediately 
after  it  was  received  and  GCS  provides  Sending  View 
Delivery  then  all  the  messages  sent  in  view  v  will  be 
delivered  before  the  next  VS  view  was  received,  and 
therefore,  before  a  new  secure  view  is  installed. 

5.3.4  Delivery  Integrity 

Theorem  5.3  If  process  p  delivers  a  message  m  in  a 
view  v,  then  there  exists  a  process  q  that  sent  m  in  v 
causally  before  p  delivered  m. 
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Proof:  The  proof  is  identical  to  the  proof  in  the  case 
of  the  basic  algorithm. 

5.3.5  No  Duplication 

Theorem  5.4  A  message  is  not  sent  twice  using  the 
key-agreement  algorithm.  The  key-agreement  algo¬ 
rithm  does  not  deliver  a  message  twice  to  the  same 
process. 

Proof:  The  proof  is  very  similar  to  the  one  in  the  case 
of  the  basic  algorithm. 

5.3.6  Self  Delivery 

Theorem  5.5  If  process  p  sends  a  message  m ,  then  p 
delivers  m  unless  it  crashes. 

Proof:  The  proof  is  identical  to  the  one  we  gave  for 
the  basic  algorithm. 

5.3.7  Transitional  Set 

We  remark  that  in  the  optimized  protocol,  when  a  se¬ 
cure  view  changes,  the  first  VS  view  notification  is 
received  in  the  M  state  while  later  cascaded  VS  mem¬ 
berships  arc  received  in  the  CM  state.  The  computa¬ 
tion  of  the  secure  transitional  set  is  the  same  as  for 
the  basic  algorithm.  Therefore,  the  arguments  we  pro¬ 
vided  to  prove  Lemma  4.6  and  Theorems  4.7  and  4.8 
are  still  valid. 

5.3.8  Virtual  Synchrony 

Theorem  5.6  Two  processes  p  and  q  that  move  to¬ 
gether  through  two  consecutive  secure  views,  deliver 
the  same  set  of  messages  in  the  former  view. 

Proof:  By  Lemma  5.2,  user  messages  arc  received  by 
the  key-agreement  algorithm  from  GCS  only  in  the  S 
or  M  states  and  as  specified  by  the  protocol,  they  arc 
delivered  as  soon  as  they  arc  received.  Therefore,  user 
messages  arc  delivered  to  the  application  only  in  the  S 
and  M  states. 

By  Lemma  5.1,  VS  membership  notifications  arc 
received  only  in  the  SJ,  CM  and  M  states.  By  the  pro¬ 
tocol  (the  way  we  compute  the  transitional  set),  if  pro¬ 
cess  p  and  q  move  together  from  vl sec  to  v2sec, 
then  p  and  q  moved  together  through  the  sequence  of 


VS  views  vl  to  v\\, ...,  vln-i  to  vln,  vln  to  v2  6.  If  n 
is  zero,  v2  will  be  received  in  the  M  state,  otherwise, 
nli  is  received  in  the  M  state  and  all  other  possible  VS 
views  (including  v2)  will  be  received  in  the  CM  state. 

Therefore,  by  the  Virtual  Synchrony  property  guar¬ 
anteed  by  GCS,  processes  p  and  q  deliver  the  same 
set  of  messages  between  vl  and  vl\,  vl\  and  vl-2,  ... 
vln  and  v2.  No  other  messages  arc  delivered  between 
v2  and  v2sec  installations  because  any  such  message 
has  to  be  sent  in  v2  by  the  GCS  Sending  View  De¬ 
livery  property.  By  the  protocol,  upon  sending  the 
flush_ok_msg  message  that  concludes  vl  each  process 
moves  to  the  M  state  and  by  Lemma  4.2,  will  not  send 
data  messages  before  installing  v2_sec.  In  particu¬ 
lar,  it  will  not  send  messages  between  v2  and  v2_sec. 
Therefore,  p  and  q  deliver  the  same  set  of  messages  in 
vlsec. 

5.3.9  Causal  Delivery 

Theorem  5.7  If  message  m  causally  precedes  mes¬ 
sage  m! ,  and  both  are  sent  in  the  same  secure  view, 
then  any  process  q  that  delivers  m!  delivers  m  before 


Proof:  The  proof  is  identical  to  the  one  provided  for 
the  basic  algorithm. 

5.3.10  Agreed  Delivery 

Theorem  5.8  If  messages  m  and  m'  are  delivered  at 
process  p  in  this  order,  and  m  and  m'  are  delivered 
by  process  q  then  m!  is  delivered  by  q  after  m  is 
delivered  by  q. 

If  messages  m  and  m!  are  delivered  by  process 
p  in  secure  view  nl  sec  in  this  order,  and  m!  is 
delivered  by  process  q  in  secure  view  v2sec  and 
message  m  was  sent  by  a  process  r  which  is  a  member 
of  secure  view  v2sec,  then  q  delivered  m. 

Proof:  The  proof  is  identical  to  the  one  provided  for 
the  basic  algorithm. 

6Note  that  n  can  be  zero  with  the  in-between  set  potentially 
empty  ( vl  to  v2). 
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5.3.11  Safe  Delivery 

Theorem  5.9  If  process  p  delivers  a  safe  message  m 
in  view  v  before  the  transitional  signal,  then  every  pro¬ 
cess  q  of  view  v  delivers  m  unless  it  crashes.  If  process 
p  delivers  a  safe  message  m  in  view  v  after  the  transi¬ 
tional  signal,  then  every  process  q  that  belongs  to  p ’s 
transitional  set  delivers  m  unless  it  crashes. 

Proof:  By  Lemma  4.7,  the  key-agreement  algorithm 
delivers  messages  with  the  same  ordering  guarantees 
with  which  they  were  delivered  by  the  group  commu¬ 
nication  system. 

By  the  algorithm,  the  first  transitional  signal  re¬ 
ceived  from  the  group  communication  system  is  de¬ 
livered  to  the  application  (see  Mark  3  in  Figures  4,  7, 
6,  5,  8,  9  and  11. 

By  the  algorithm,  the  transitional  set  delivered  with 
a  new  secure  membership  notification  is  calculated 
as  follows,  when  a  group  change  happens  while  the 
group  is  stable  (state  S),  the  transitional  set  is  initial¬ 
ized  to  the  current  secure  membership  list  (see  Figures 
10  and  11,  Mark  4)  and  then  every  time  another  VS 
membership  notification  is  received  from  GCS  before 
installing  this  secure  view,  the  members  that  left  the 
group  are  removed  from  the  transitional  set  (see  Fig¬ 
ure  9  and  11,  Mark  5),  such  that  when  the  new  secure 
membership  notification  is  delivered,  the  transitional 
set  is  correct.  Therefore,  the  safe  delivery  require¬ 
ments  arc  preserved. 

6  Conclusions 

Implementing  secure  and  robust  handling  of  cas¬ 
cading  group  events,  using  an  approach  optimized  for 
the  most  frequent  events  (join  and  leave),  is  crucial 
in  order  to  have  a  complete  secure  group  communi¬ 
cation  system.  Hardening  security  protocols  to  make 
them  robust  to  asynchronous  network  events  although 
difficult  is  possible.  This  work  provides  two  robust 
key  agreement  algorithms.  We  prove  that  by  integrat¬ 
ing  them  with  a  group  communication  systems  sup¬ 
porting  Virtual  Synchrony,  the  group  communication 
membership  and  ordering  guarantees  arc  preserved. 

We  intend  to  implement  the  optimized  protocol  in 
the  Secure  Spread  system.  In  addition  we  intend  to 
explore  and  experiment  with  robustness  and  recovery 


techniques  for  a  spectrum  of  other  group  key  manage¬ 
ment  mechanisms,  such  as  the  centralized  approach 
and  the  Burmester-Desmedt  protocol. 

Finally,  several  necessary  services  for  a  secure 
group  communication  could  lead  to  interesting  future 
work.  They  include  services  such  as  group  member 
certification,  intra-group  authentication,  private  com¬ 
munication  within  a  group  and  private  communication 
between  members  and  non-members  of  the  group. 
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